diff --git a/data/web/corefork.telegram.org/api/peers.html b/data/web/corefork.telegram.org/api/peers.html index 13f406ea13..5181edf879 100644 --- a/data/web/corefork.telegram.org/api/peers.html +++ b/data/web/corefork.telegram.org/api/peers.html @@ -111,7 +111,13 @@ Info about these IDs may be fetched with the zero access hash even by users.
After invoking bots.setBotInfo after changing name
(but not the about
or the description
, as changing those fields already triggers a refresh of the full info database, and with it the peer database), for the bot whose info we changed
After receiving a CHAT_FORWARDS_RESTRICTED
error when forwarding messages from a chat, to refresh info about the source chat.
After receiving a CHAT_FORWARDS_RESTRICTED
error when forwarding messages from a chat, to refresh info about the source chat (i.e. the fact that we received this error means that the client didn't locally prevent the user from forwarding a message from the protected chat, because the locally cached channel.noforwards
/chat.noforwards
flag is out of date).
After receiving a CHAT_GUEST_SEND_FORBIDDEN
error when sending messages to a discussion group, to refresh info about the discussion group (i.e. the fact that we received this error means that the client didn't locally prevent the non-member user from sending a message to a discussion group where only members can send messages, because the locally cached channel.join_to_send
flag is out of date).
After receiving a USER_NOT_PARTICIPANT
error when calling channels.leaveChannel, to refresh info about the channel/supergroup (i.e. the fact that we received this error means that the client tried to leave a channel/supergroup they're not a member of, and the client didn't try to prevent this locally because its channel constructor is out of date).
After invoking the following methods (both if the call succeds and after receiving a USERNAME_NOT_MODIFIED
error, which is also a success):
Info should only be manually refreshed with a call to users.getUsers, channels.getChannels if the new username order/active username cannot be applied locally (i.e. the method call successfully set as active some username that isn't associated to the peer in our local cache, and so on), otherwise the username
and usernames
fields of the peer info database should be updated locally, using the info that was passed to the toggle/reorder methods by the user.
Do not refresh peer information in any other case, to avoid overloading the server by continuously requesting changes for the same unchanged information.
+Do not manually refresh peer information in any other case, to avoid overloading the server by continuously requesting changes for the same unchanged information.
The peer info database contains the following information:
The full info database needs to be updated every time a new constructor of type userFull, chatFull and channelFull is received, by completely replacing the locally cached entry.
-These constructors may only be received with a manual call to
+The full info database contains info from the userFull, chatFull and channelFull constructors.
+To populate the full info database for a peer, manually invoke users.getFullUser, messages.getFullChat, channels.getFullChannel, all requiring the previously cached access_hash » when the client needs to use one of the full info fields.
+Full info must be manually refreshed and stored to the database with a method call to the above methods only in the following conditions (i.e. do not refresh user info when opening the profile page, and so on...):
+Do not refresh full peer information in any other case, to avoid overloading the server by continuously requesting changes for the same unchanged information.