Skip to content

Display whether streams are web-public streams in stream name decorations #1135

@timabbott

Description

@timabbott

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:

{{#if invite_only}}
<i class="fa fa-lock" aria-hidden="true"></i>
{{else if is_web_public}}
<i class="fa fa-globe" aria-hidden="true"></i>
{{else}}
<span class="hashtag"></span>
{{/if}}

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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions