You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As we prepare for it being possible to have web-public streams in a Zulip server (#18532), we should make sure the terminal app decorates any web-public streams correctly when they are displayed in the UI. The web application currently does so with a fa-globe in the places that the # or fa-lock icon appears decorating a stream name:
The purpose of this decoration is to indicate to the user their messages may have a wider audience than is normal for just a public stream; so most important is that it be displayed prominently when composing messages. We should do similar display in the terminal app. I don't think any other behavior changes are strictly required for the terminal app to be functional in the presence of this new feature, though eventually the "Create stream" UI should support making them.
Today, we merged the big chunk of #18532 that makes it possible to create web-public streams in the API with a server-level settings WEB_PUBLIC_STREAMS_ENABLED set, which is currently only true in the development environment. (I also note that the development environment has a Rome stream that is web-public by default). It's reasonably likely that we'll create a web-public stream in chat.zulip.org for community QA by the end of the month, since the unmerged section of #18532 is shrinking rapidly. CC @amanagr.
The is_web_public flag has been present in stream objects (in /register since Zulip 2.1; in events since feature level 73).
In theory, we could also add web-public stream browsing support to the terminal app; if that becomes a priority for you, I can do a writeup on what'd be involved. Because most of the work is done at the API level, it might be only of moderate complexity; certainly there's only a modest amount of web application code for this feature. Basically, we added:
An if(spectator) { specators.login_to_access() } popup flow for what happens when you try to do something like add an emoji reaction that requires an account.
Added a hidden_for_spectators CSS class that hides various UI elements (e.g. popover menu items) that are never going to be relevant for spectators.
Adjusted 401 errors for API requests to also do the pop up.
Added a top-of-page banner explaining what's happening.
Possibly adjusted outgoing GET /messages type API requests to pass an is:web_public narrow parameter, though this detail is under active discussion.
The text was updated successfully, but these errors were encountered:
As we prepare for it being possible to have web-public streams in a Zulip server (#18532), we should make sure the terminal app decorates any web-public streams correctly when they are displayed in the UI. The web application currently does so with a
fa-globe
in the places that the#
orfa-lock
icon appears decorating a stream name:The purpose of this decoration is to indicate to the user their messages may have a wider audience than is normal for just a public stream; so most important is that it be displayed prominently when composing messages. We should do similar display in the terminal app. I don't think any other behavior changes are strictly required for the terminal app to be functional in the presence of this new feature, though eventually the "Create stream" UI should support making them.
Today, we merged the big chunk of #18532 that makes it possible to create web-public streams in the API with a server-level settings
WEB_PUBLIC_STREAMS_ENABLED
set, which is currently only true in the development environment. (I also note that the development environment has aRome
stream that is web-public by default). It's reasonably likely that we'll create a web-public stream in chat.zulip.org for community QA by the end of the month, since the unmerged section of #18532 is shrinking rapidly. CC @amanagr.The
is_web_public
flag has been present in stream objects (in/register
since Zulip 2.1; in events since feature level 73).In theory, we could also add web-public stream browsing support to the terminal app; if that becomes a priority for you, I can do a writeup on what'd be involved. Because most of the work is done at the API level, it might be only of moderate complexity; certainly there's only a modest amount of web application code for this feature. Basically, we added:
if(spectator) { specators.login_to_access() }
popup flow for what happens when you try to do something like add an emoji reaction that requires an account.hidden_for_spectators
CSS class that hides various UI elements (e.g. popover menu items) that are never going to be relevant for spectators.GET /messages
type API requests to pass anis:web_public
narrow parameter, though this detail is under active discussion.The text was updated successfully, but these errors were encountered: