| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
The current user ID is located on the `user` structfield in the cache,
and is not directly on the cache.
|
| | |
|
| |
|
|
| |
else
|
| |
|
|
| |
Removed action support from the builtin one as well, due to it adding some uneccassery complexity and it being only asked upon by one user
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
It's already been enough time for people to migrate
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Nonces can actually be almost anything - including booleans - so just
use a Value to represent it since very few users will need it.
This fixes errors like:
```
WARN:serenity::internal::ws_impl: (╯°□°)╯︵ ┻━┻ Error decoding: {"t":"MESSAGE_CREATE","s":12187872,"op":0,"d":{"type":0,"tts":false,"timestamp":"2017-06-01T01:00:00.000000+00:00","pinned":false,"nonce":"","mentions":[{"username":"redacted","id":"redacted","discriminator":"redacted","avatar":"redacted"}],"mention_roles":[],"mention_everyone":false,"id":"redacted","embeds":[],"edited_timestamp":null,"content":"redacted","channel_id":"redacted","author":{"username":"redacted","id":"redacted","discriminator":"redacted","bot":true,"avatar":"redacted"},"attachments":[]}}
ERROR:serenity::client: Shard handler received err: Json(ErrorImpl { code: Message("Unknown i64 value: "), line: 0, column: 0 })
```
and:
```
WARN:serenity::internal::ws_impl: (╯°□°)╯︵ ┻━┻ Error decoding: {"t":"MESSAGE_CREATE","s":1001192,"op":0,"d":{"type":0,"tts":false,"timestamp":"2017-06-01T01:01:01.000000+00:00","pinned":false,"nonce":true,"mentions":[],"mention_roles":[],"mention_everyone":false,"id":"redacted","embeds":[],"edited_timestamp":null,"content":"bork","channel_id":"redacted","author":{"username":"redacted","id":"redacted","discriminator":"redacted","bot":true,"avatar":"redacted"},"attachments":[]}}
ERROR:serenity::client: Shard handler received err: Json(ErrorImpl { code: Message("invalid type: boolean `true`, expected identifier"), line: 0, column: 0 })
```
|
| |
|
|
|
|
|
| |
Deprecate `Channel::delete_messages` and `Channel::delete_permission`.
These methods aren't available on all of the variants' types, so they
shouldn't be on the Channel either.
|
| | |
|
| |
|
|
|
|
| |
Switch from using `#[doc(hidden)]` to hide some internal functions to
`pub(crate)`.
The library now requires rustc 1.18.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Negative message nonces caused deserialization errors, as serde would
not deserialize integers into strings.
To fix this, change `Message::nonce` into an `Option<Snowflake>` from an
`Option<String>`. This new `Snowflake` is a wrapper around an `i64`. Use
a new `I64Visitor` to deserialize i64s, u64s, and strs into the wanted
i64.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Chrono is easier to use than timestamped strings, so they should be
automatically deserialized and available for the user, instead of having
the user deserialize the strings themselves.
These fields have been changed to use a type of `DateTime<FixedOffset>`:
- `ChannelPinsUpdateEvent.last_pin_timestamp`
- `Group.last_pin_timestamp`
- `Guild.joined_at`
- `GuildChannel.last_pin_timestamp`
- `Invite.created_at`
- `Member.joined_at`
- `Message.edited_timestamp
- `Message.timestamp`
- `MessageUpdateEvent.edited_timestamp`
- `MessageUpdateEvent.timestamp`
- `PrivateChannel.last_pin_timestamp`
`Member.joined_at` is now also an `Option`. Previously, if a Guild
Member Update was received for a member not in the cache, a new Member
would be instantiated with a default String value. This is incorrect
behaviour, and has now been replaced with being set to `None` in that
case.
Id methods' `created_at()` method now return a `chrono::NaiveDateTime`
instead of a `time::Timespec`, and `User::created_at` has been updated
to reflect that.
Additionally, drop `time` as a direct dependency and use chrono for
internals.
|
| |
|
|
|
|
| |
Helper methods such as `GuildChannel::send_files` linked to the
documentation for `ChannelId::send_file`, when they should be linking
to `ChannelId::send_files`.
|
| |
|
|
|
| |
With the way AttachmentType is meant to be used by `http::send_files`,
none of the values need to be moved, they only need to be borrowed.
|
| |
|
|
|
| |
The method can be used as a shortcut for retrieving a message's channel
from the cache.
|
| |
|
| |
Deprecate `Role::edit_role` and rename it to `Role::edit`.
|
| | |
|
| | |
|
| |
|
|
| |
This can be used as a helpful shortcut for reactions.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Remove the deprecated GuildChannel methods in preparation of an
incoming commit modifying GuildChannel.
Remove the following deprecated methods:
- `get_invites`
- `get_message`
- `get_messages`
- `get_reaction_users`
- `get_webhooks`
|
| |
|
|
|
|
|
|
|
|
|
| |
If http::send_file received a non-success status code due to reasons
such as sending to an invalid channel Id, not having permissions, or
sending too large of a file, then it would still try to deserialize
a response as if it were valid.
To fix this, ensure that the response is successful. Document that if
the file sent is too large, then
`HttpError::InvalidRequest(PayloadTooLarge)` is returned.
|
| |
|
|
| |
A link to model::permissions::SEND_MESSAGES was broken.
|
| |
|
|
|
|
| |
The examples didn't bring `model::PermissionOverwriteType` into scope.
Additionally, wrap the examples in try_main's to make use of the `?`
operator.
|
| |
|
|
|
| |
{ChannelId,GuildChannel}::create_permission don't need to take
ownership over the overwrite, so just accept a reference.
|
| |
|
|
|
| |
The struct was previously in `src/model/channel/message.rs` instead of
its own `src/model/channel/reaction.rs` file.
|
| | |
|
| |
|
|
| |
These reactions are added onto the `MessageCreate` builder, and are sent
after the message has been created.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modules are now separated into a fashion where the library can be used
for most use cases, without needing to compile the rest.
The core of serenity, with no features enabled, contains only the
struct (model) definitions, constants, and prelude. Models do not have
most functions compiled in, as that is separated into the `model`
feature.
The `client` module has been split into 3 modules: `client`, `gateway`,
and `http`.
`http` contains functions to interact with the REST API. `gateway`
contains the Shard to interact with the gateway, requiring `http` for
retrieving the gateway URL. `client` requires both of the other features
and acts as an abstracted interface over both the gateway and REST APIs,
handling the event loop.
The `builder` module has been separated from `utils`, and can now be
optionally compiled in. It and the `http` feature are required by the
`model` feature due to a large number of methods requiring access to
them.
`utils` now contains a number of utilities, such as the Colour struct, the
`MessageBuilder`, and mention parsing functions.
Each of the original `ext` modules are still featured, with `cache` not
requiring any feature to be enabled, `framework` requiring the `client`,
`model`, and `utils`, and `voice` requiring `gateway`.
In total the features and their requirements are:
- `builder`: none
- `cache`: none
- `client`: `gateway`, `http`
- `framework`: `client`, `model`, `utils`
- `gateway`: `http`
- `http`: none
- `model`: `builder`, `http`
- `utils`: none
- `voice`: `gateway`
The default features are `builder`, `cache`, `client`, `framework`,
`gateway`, `model`, `http`, and `utils`.
To help with forwards compatibility, modules have been re-exported from
their original locations.
|
| |
|
|
| |
We removed these a long time ago, and these were missed.
|
| |
|
|
| |
Add a method to calculate a member's permissions in the channel.
|
| |
|
|
|
|
|
|
|
|
| |
When message type 7 is received from the gateway, transform the content
if the type is 7 to a proper greeting.
Additionally, when the type is 6, provide a proper content notifying that a
user has pinned a message to the channel.
These transformations are not done at REST-level when retrieving messages, and
are instead done in `ChannelId::message` and `ChannelId::messages`.
|
| | |
|
| | |
|
| |
|
|
|
| |
By accepting references, users don't have to either pass in the entirity
of an instance or clone it.
|
| |
|
|
|
|
|
|
|
| |
Deserializing a non-custom emoji would fail, as an Id would always be
expected.
To fix this, special-case that if a name and id are both present, to
deserialize it as a Custom emoji reaction. Otherwise, use only the name
and deserialize as a basic reaction.
|