User only methods #25
Conversation
|
about the joinchat method |
|
@giuseppeM99 Okay. So the joinChat method takes a chat_id parameter which can be a numerical id or the username (like everywhere in the api). So it is possible to join nearby chats by chat_id as well. I could add an invite_link parameter, that is exclusive to the chat_id, but I'm not sure if this is the nicest solution. I'm also not sure what to do if someone enters something like "t.me/tdlightchat" as invite_link, we should probably fail this query cause there are dozens of alias domains for t.me |
|
@code1mountain the bot api unifies many methods into one, i would make joinchat be able to handle either chat_id (username / id) or joinlink, so it will have two parameters (chat_id and joinlink) and you must enter at least 1 in the request then: joinchat?chat_id=xxxx chat_id must work with username and id |
|
Some naming suggestions:
There is no real action in there. Alternatives:
On top of that, should we fare differently with quizzes and polls? MTProto considers a quiz a special type of poll and we also can't check the type before making the request (thanks @code1mountain for those infos), but from a user view maybe it'd be useful when they search for "quiz" and find everything relevant in the list.
I agree that those should be unified and parametrized.
From a user view, I would like to have:
Those do not include the word "chat" however, so you won't find them when searching for that.
How about
Both say "send" but they're kind of different 🤔 Should one be
Means we will also get Do we need |
|
@JosXa dialogs are so low level they're not even mentioned in tdlib's methods, as this is an abstraction layer built on top of tdlib, i don't think we should go deeper and re-introduce another concept of dialog that will inevitably be different than the low level mtproto counterpart |
|
@giuseppeM99 Ah, I wasn't aware! That's why the other mtproto libs have it, understood. |
|
@andrew-ld The joinchat method only returns ok, while the joinChatByInviteLink returns a chat object. Should I unify it by returning a chat object anyway? |
|
@code1mountain yes |
spontanurlaub
force-pushed
the
user-methods
branch
from
97a15d2
to
821fbb6
Compare
I would go with |
how about an unified
|
| Field | Type | Description |
|---|---|---|
| type | String | Type of chat, can be either “private”, “group”, “supergroup” or “channel” |
this would simplify the search, and also be consistent with the Chat object.
Thinking about it, as we cannot emulate "clicking on a URL button", I agree with centering this around callback data. However what's weird to me is that "sending" is usually around messages, not machine-specific implementation details. Therefore, I would urge to find a name similar to It is named "the data of a callback" (aka payload) after all, so "calling back" is what this method should represent. My favorite would be |
|
Same should go for inline queries I feel, where "sending" is absolutely valid for an individual inline query result, but firing the |
|
With |
Creating a basic group requires a title and a list of members to be added (Not sure if it can be an empty list, but I assume). Creating a supergroup or channel requires a title, a description (may be empty) and optionally a location. So a
Adding members to a group can be done later, it's also not the best way to get people to join your group. |
|
For |
|
|
@code1mountain
In the native clients that's not possible. Can someone confirm using raw mtproto? |
|
as far as i remember, you can't create an empty group |
|
So we needs something like a Should we support the same argument for other groups, too? |
|
I added an alias |
|
I will not add any new features to this pull request and the documentation is pretty much ready (just some discussion on how/where to deploy it, that's why I have it here for now). Please review and test the code, so we can deploy the documentation and this Pull Request at the same time? PS: Can someone please help me merging the conflicts? Never done this before. |
|
@code1mountain Please make sure it's authPath and the same camelCase for the login in the docs, so we stay consistent |
# Conflicts: # telegram-bot-api/Client.cpp # telegram-bot-api/Client.h
|
(Let's not use [WIP] in titles, use the "draft PR" feature) |
|
I added message scheduling to this commit, because it took longer to merge than expected and I used some code from the other added methods. All Scheduled messages have a negative The existing methods |
| if (arg < 0) { | ||
| return 0; | ||
| } | ||
| // if (arg < 0) { |
There was a problem hiding this comment.
Why did you remove this check?
There was a problem hiding this comment.
Scheduled messages have negative message ids. Therefore this check if the message_id is negative breaks scheduled messages.
There was a problem hiding this comment.
Ok, but this could possibly break other methods that expect the message_id to be positive, especially with bots that can't schedule messages, or methods that should work with non scheduled messages, adding a parameter to allow negative numbers would be fine for me
There was a problem hiding this comment.
The check basically moved to as_tdlib_message_id. There it uses the old conversion (20 bit shift) only for positive message_ids. It still has the same check for positive numbers and an other behaviour for negative ones.
There was a problem hiding this comment.
This doesn't work because get_message_id is a static function.
|
@code1mountain what's the status of this? Are you just waiting for our review? |
|
Yes, mainly waiting for review. |
This PR contains a bunch of user only methods.
Plans for the future (Not this PR, they need many new classes):
The new methods will be documented in a machine readable format, probably
openAPI, so we can generate a Swagger documentation. It doesn't make sense to document them in the readme, which becomes too messy.Progress tracking
getInlineQueryResults(sending an inline query to a bot)getChats(Normal chat list)getCommonChats(Common chats with an other user or bot) * (There is currently a bug in tdlight which causes this method to fail, hopefully it will be fixed soon.)getInactiveChats(When reaching the limit of available supergroup chats)getNearbyChats(Search chats by location)searchPublicChats(Searches public chats by looking for specified query in their username and title.)votePoll(For voting in polls or quizzes and retracting votes)joinChat(join a chat by username/chat id or invite_link)joinChatByInviteLink(join a chat by invite link)createChat(Create a group, supergroup or channel)addChatMember(add a user to a group or channel)getCallbackQueryAnswer(Interacting with inline Keyboards)sendInlineQueryResultMessage(selecting an inline query to send)searchMessages(for searching messages globally)searchChatMessages(for searching messages in a chat)deleteChatHistory(delete Chat History in a private chat, group or channel)reportChat(report a group or a user for spam)If I miss any important methods, please let me know. I'm also open for better name suggestions or other comments.