These fields are present in the docs, and I tested it manually by calling the `get_chat_member` method with the changed `teloxide-core` code that parsing still works fine for the `Restricted` chat member.
There are however some potential logic bugs here described bellow. I fixed some of them, but others are still outstanding.
\# Logic bugs
\## Shared permission fields in `Administrator` and `Restricted`
The current code of `teloxide-core` at the time of this writing doesn't take into account the shared permission fields of `Administrator` and `Restricted` because just were no such fields in `Restricted` struct. This bug is fixed by this PR.
\## Deceiving behavior of `ChatMemberKind::Member`
The existing getter methods of `ChatMember` assume that if the `ChatMemberKind` is `Member`, then the member has all rights for all fields of `Restricted` struct.
And there is also a similar problem with `Administrator` struct.
The existing getter methods of `ChatMember` assume that if the `ChatMemberKind` is `Member`, then the member has no rights for all fields of `Administrator` struct.
This isn't always true. Regular members *may or may not have* `can_invite_users` permission, for example. This is determined by the default chat parmissions. See bellow.
\# General decieving behavior of permission getters
The default chat permissions seem to override any cofigurations of `Restricted` chat members.
For example, if the `Restricted` chat member has `can_invite_users` set to `true`, but the default chat permissions have `can_invite_users` set to `false`, then the effective `can_invite_users` permission of such a user is `false` (verified experimentally).
Therefore, the getters for the permission fields of the `ChatMember` type actually don't make sense. They don't show the effective permissions of the user. Maybe we could make that clear in their docs, but the problem is that these getters don't have enough context to decide what to return for regular `ChatMemberKind::Member`.
I am not sure how to proceed here. For example, these getters could return `Option` values, and always return `None` for `ChatMemberKind::Member`.
I didn't fix that bug in this PR, because I believe it requires a more careful consideration, larger and potentially breaking changes, that I am not ready to do.
\# Intentionally left as not in scope of this PR
Telegram added topics feature recenenty, and consequently they added `can_manage_topics` field both to `Administrator` and `Restricted` structs. This field is not present in the current code of `teloxide-core` at the time of this writing, and I think it should be added in a separate PR that covers topics API as a whole.
Also, one discrapancy with the new `can_manage_topics` field is with its type and documentation.
Here is how this field looks like in `ChatMemberAdministrator` **and** `ChatAdministratorRights`:
```
can_manage_topics Boolean Optional. True, if the user is allowed to create, rename, close, and reopen forum topics; supergroups only
```
Here is how this field looks like in `ChatMemberRestricted`:
```
can_manage_topics Boolean True, if the user is allowed to create forum topics
```
Here is how this field looks like in `ChatPermissions`:
```
can_manage_topics Boolean Optional. True, if the user is allowed to create forum topics. If omitted defaults to the value of can_pin_messages
````
There is something subtle between the semantics of `can_manage_topics` for regular users and administrators according to the difference in their documentation. I didn't dig into that rabbit hole, so I intentionally didn't include topics feature changes in this PR.
