The GitHub API provides `ref_type` as lowercase. For consistency, this
adds a utility function and makes use of it when formatting the `create`
event from GitHub.
tag => Tag
branch => Branch
I've created a middleware that runs when `/github` is appended to the
webhook URL. The middleware parses the GitHub webhook and turns it into
usable embeds.
The biggest hold-up was missing fields (`premium_tier`,
`welcome_screen`, etc.) but it looks like someone has provided a
helpful function called `createGuild(...)` to provide sensible default
values.
This commit fixes the errors related to creating a guild from a
template. I've also refactored the code to include roles and channels in
the template.
To make sure that the @everyone role is cloned correctly, when
creating the guild from a template, we check if the role's ID
matches the template's `source_guild_id`. If it does, we set the
@everyone role to the new guild's ID.
I think we'll need to discuss the proper way to provide default values
here. `premium_tier` for example should never be provided from the
template so it's fine going after the spread operator.
This commit still doesn't allow guilds to be created from template
because the next error is that `welcome_screen` doesn't exist. Our
options:
1. Provide default values in the ORM
2. Provide default values in the guild creation process
3. Throw an error if the template is missing values
Resolves: #1283 but creates a new issue
`Promise.all(...)` runs these simultaneously, yet role depends on the
guild to be created first. This can lead to a race condition. I've
awaited role creation too because the call to `Member.addToGuild(...)`
relies on the role to be created.
The previous PATCH implementation was creating a new template rather
than editing the existing template. This resulted in all requests
failing because it was missing more than one required field.
Resolves: #1281
The `message.message_reference` stores:
1. `message_id`
2. `channel_id`
3. `guild_id`
We use the `message_id` and `channel_id` to `.findOne(...)` Message, and
find the author. If the author is the same as OP, we skip (so replying
to yourself doesn't add you to the mentions array) otherwise, it adds
the author_id to the mentions array.
Resolves: #1247
In a previous PR, I was checking if the `.url` property existed, the
correct fix is to remove any embed that isn't a rich embed
type (non-link).
See also: #1296
In a previous commit I was attempting to be clever by only
replacing/removing embeds if necessary. This not only made the logic
more confusing but introduced a bug that would allow for orphaned
embeds when updating the search params of a URL.
This commit will remove all embeds that have a `.url` property and start
fresh. This simplifies the code and eliminates the aforementioned bug.
The `postHandleMessage` function is parsing links and adding them to the
EmbedCache table if necessary. In the previous implementation, message
updates would push to the embeds unconditionally.
This commit parses links from the message and:
1. Normalizes the URLs
- Useful for deduplicating similar URLs
2. Remove embeds with matching normalized URLs
- Leaves all embeds except for ones with a `.url` property matching
the updated message
- This allows embeds to be re-ordered if the URL is moved
3. If no normalized URLs are found, remove all embeds
4. Take the deduplicated + normalized URLs and add an embed to the message and
insert into the EmbedCache table (if necessary)
This enables:
1. Embeds to be re-ordered by re-ordering links
2. Embeds to be removed by removing links
and fixes:
1. Duplicate embeds being attached to a message when edited
