Skip to main content

v4.2.0 Patch-Notes

· 5 min read
Snawe

I am happy to announce v4.2.0! 😃

This update brings 2 new quality of life features, some improvements and bugfixes!

Features​

Notification Rewrite​

Customization​

  • event_start_notification now allows full* customization for Premium users.
  • event user notify also allows full* customization now, but für all users (as before).

You can both edit the Text Message field of a Discord message (this is where you can for example ping @user) and the Embed Message (in here you can use for example links with [link name](link url))

* Sadly only the Embed Description is currently up for customization. The Embed Title isn't enabled yet due to a Discord limitation for which I need to find a workaround.

note

There are 2 differences from the event user notify command to the event_start_notification:

  • event user notify is a manual (one time) trigger.
  • event user notify allows customization of messages also for none Premium users!

New Commands​

  • event_start_notification edit message to edit the notifications message
  • event_start_notification edit notify_type to edit the notifications notify_type
  • event_start_notification list to list all entries

Premium​

Premium users can now use more than 1 event_start_notification per server. This allows you to send different messages at "1 day" before event start and another one "5 minutes" before the event starts. Or you can send a message once to users that aren't signed up yet and another message to users that are signed up.

Relative Date/Time Support​

Till now you needed to enter a full date/time when creating an event. Like 2023-05-14 20:00.

NOW you can use stuff like tomorrow 20:00 or today 1h!

So what are valid options and how to they resolve?

  • now => creates an event with the date of today and a start/end time of now
  • today => creates an event with the date of today and no start/end time
  • tomorrow => creates an event with the date of tomorrow and no start/end time

Combine! You can combine now, today and tomorrow with either a precise time (like 08:00pm) or a relative time (1h 10m) Examples:

  • today 20:30 will resolve in the date of today and the start/end time of 20:30
  • today 1d 30m will resolve to the date of tomorrow (1d) and the time of you executing the command + 30 minutes. So this would actually be the same as tomorrow 30m.

Read more about that feature here.

Bugfixes​

  • Fixed issue that a "channel" notification (former "ping" message) got printed with "Pinged 0 users" if no users met the required sign up state.
  • Fixed issue that the wrong event start time was shown in the notification message footer.
  • Fixed issue that events do not get created via a repeating event entry, once the repeating event entry was deactivated once. Even after setting it to active again.
  • Fixed issue that events with an end time in the past did not get deleted immediately if the event_deletion_time was over. Instead they got deleted with a delay of a few minutes. This is currently mainly caused by repeating event entries if they get activated again. On activate the bot creates all missed events. Since the deletion does not happen instantly, it causes a lot of confusion and also unnecessary API calls (like sending notification messages, creating and deleting voice channels, ...). I am working on a solution that the bot will skip those events in general. But till than, this is a workaround.
  • You now get a "missing permission" error if the bot misses access to the channel during the event user notify command.
  • If the signup_template had invalid limit fields (due to manual edit of the .json file), so sign ups were possible. This is now fixed by ignoring invalid fields and using default values for missing fields.
  • Fixed an issue that Discord server with a timzone in UTC+2 (or higher) were not possible to create events within the new future (next few hours).

Improvements​

  • Most missing permission message now have a link directly to the doc page with additional information about the permission required.

Other Changes​

  • Related to the Notification Rewrite, the notification types were renamed from "ping" and "message" to "Channel" and "DM" because the "ping" message got always printed to a server channel, while the "message" was always a DM to a user.

  • Added the fields:

    • ${signup_state} resolves to "sigend up", "not sigend up" or "confirmed", depending on the choosen state.
    • ${maching_users} resolves to all users that match the state and mentions (@user) them.

    Those fields can be used with the different notification commands. Read here for more information.