morethanwords/tweb/master •
b9d75a0 •
10 files, +123/-40Polish the Community chats panel
A bot linked to a Community shows up in "Chats you can view" as an ordinary
dialog row, and until its chat is started it has no last message at all, so the
row was left with an empty subtitle. It falls back to the peer's own status now
— "bot", the string the request-to-join and hidden sections already use and
what tdesktop puts under such a row. The fallback lives in one place with the
botforum's "no messages yet" and applies only to rows that belong to a
Community list, so the main chat list keeps its blank subtitle.
The header carried the Community name alone, while every forum tab has a second
row under its title. It now says how many chats the Community has, counted from
the linked peers the same way the Community row in the chat list counts them.
The avatar moved out of the title into a slot the forum tab itself provides, so
the title and the subtitle keep the shared sidebar-header styles instead of a
private copy that had to override their padding; that shared inline padding is
2px wider now, for every forum header.
Opening a chat from the panel rebuilt its row. The projection runs several
times per open — the dialog, the peer and the read state all move — and every
pass reappended each row to its list, reinserted the hidden-chat icon and
rewrote the dataset. Reappending a node that is already in place still detaches
it, taking everything rendered inside it down with it. Rows are positioned by
index now, which does nothing while the order holds, and the icon and the
dataset are only written when they actually change: an open went from 29 DOM
mutations to the three the click itself makes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
morethanwords/tweb/master •
7577288 •
8 files, +146/-23Stop offering menu actions that aren't available
Editing a Community was offered to every member of it. hasRights ran a
Community through the group branch, where change_info is a member right that
the default banned rights can only take away, and on top of that granted
change_info outright when the Community carried no rights object at all — so
canEditCommunity, which starts at change_info, was true for anyone. A Community
is administered like a channel: tdesktop maps it to a channel without the
megagroup flag, so its canEditInformation() asks for the granted admin right or
the creator, and tweb's own Community admin editor already lists change_info
among the four rights an admin is given. hasRights agrees now — change_info and
invite_users on a Community need that admin right.
That leaves a member looking at a menu button that opens nothing. The toggle
already refuses to open a menu whose every item failed its verify, but the
button itself stayed on screen. The Community tab rechecks its items whenever
the Community changes and hides the trigger while none of them pass; the check
is the one the shared media header was already doing, moved next to
filterButtonMenuItems so both go through the same code.
"View as topics" had the same shape of problem: its only condition was the
dialog's view_forum_as_messages flag, which outlives the forum it was set for,
so the action showed up for chats that are not forums at all and would have
opened a topics list that does not exist. The chat list menu and the chat
header now ask the peer whether it is a forum first, the way tdesktop's
addViewAsTopics does.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
#webk
