diff --git a/docs/production/authentication-methods.md b/docs/production/authentication-methods.md index e66067283d..7dc00e8f73 100644 --- a/docs/production/authentication-methods.md +++ b/docs/production/authentication-methods.md @@ -153,7 +153,7 @@ login form. You may also want to configure Zulip's settings for [inviting new users](https://zulip.com/help/invite-new-users). If LDAP is the only enabled authentication method, the main use case for Zulip's -invitation feature is selecting the initial streams for invited users +invitation feature is selecting the initial channels for invited users (invited users will still need to use their LDAP password to create an account). diff --git a/docs/production/email-gateway.md b/docs/production/email-gateway.md index 7671c1eddf..1bf3e1bc69 100644 --- a/docs/production/email-gateway.md +++ b/docs/production/email-gateway.md @@ -12,9 +12,9 @@ because it enables: documentation](https://zulip.com/integrations/doc/email) for details. -Once this integration is configured, each stream will have a special -email address displayed on the stream settings page. Emails sent to -that address will be delivered into the stream. +Once this integration is configured, each channel will have a special +email address displayed on the channel settings page. Emails sent to +that address will be delivered into the channel. There are two ways to configure Zulip's email gateway: diff --git a/docs/production/export-and-import.md b/docs/production/export-and-import.md index 3424d8bdc0..98e78fad09 100644 --- a/docs/production/export-and-import.md +++ b/docs/production/export-and-import.md @@ -59,7 +59,7 @@ service (or back): - Zulip also has an [HTML archive tool](https://github.com/zulip/zulip-archive), which is primarily intended for public archives, but can also be useful to - inexpensively preserve public stream conversations when + inexpensively preserve public channel conversations when decommissioning a Zulip organization. - It's possible to set up [PostgreSQL streaming @@ -264,7 +264,7 @@ a few downsides in comparison: - All users will have their passwords randomized and be logged out of their accounts, both on web and mobile clients. - All bots and integrations will need to be updated with new API keys. -- Users, streams, and messages are usually renumbered, which will +- Users, channels, and messages are usually renumbered, which will break most links from external programs referencing these objects. ### Consider upgrading diff --git a/docs/production/mobile-push-notifications.md b/docs/production/mobile-push-notifications.md index 8f0ddf82c0..8dd02a79fd 100644 --- a/docs/production/mobile-push-notifications.md +++ b/docs/production/mobile-push-notifications.md @@ -173,7 +173,7 @@ and privacy in mind: - The numeric message ID generated by your Zulip server. - Metadata on the message's sender (name and avatar URL). - - Metadata on the message's recipient (stream name + ID, topic, + - Metadata on the message's recipient (channel name + ID, topic, direct message recipients, etc.). - A timestamp. - The message's content. diff --git a/docs/production/requirements.md b/docs/production/requirements.md index 6e5c9818ee..8c00005995 100644 --- a/docs/production/requirements.md +++ b/docs/production/requirements.md @@ -206,14 +206,14 @@ installing Zulip with a dedicated database server. - **Disk for database:** SSD disk is highly recommended. For installations where most messages have <100 recipients, 10 GB per 1M messages of history is sufficient plus 1 GB per 1000 users is - sufficient. If most messages are to public streams with 10K+ users + sufficient. If most messages are to public channels with 10K+ users subscribed (like on chat.zulip.org), add 20 GB per (1000 user - accounts) per (1M messages to public streams). + accounts) per (1M messages to public channels). - **Example:** When [the Zulip development community](https://zulip.com/development-community/) server had 12K user accounts (~300 daily actives) and 800K messages of - history (400K to public streams), it was a default configuration + history (400K to public channels), it was a default configuration single-server installation with 16 GB of RAM, 4 cores (essentially always idle), and its database was using about 100 GB of disk. diff --git a/docs/production/scim.md b/docs/production/scim.md index a264a70bf5..241947e1cd 100644 --- a/docs/production/scim.md +++ b/docs/production/scim.md @@ -51,10 +51,10 @@ The Zulip server-side configuration is straightforward: ## Additional options -- To enable the creation of guest accounts without automatically subscribing them to any initial streams, +- To enable the creation of guest accounts without automatically subscribing them to any initial channels, add `"create_guests_without_streams": True` to your client's config dict in `SCIM_CONFIG`. This option is particularly useful for organizations that prefer to manually invite new guest users - to the appropriate streams. + to the appropriate channels. Example configuration with the additional option: diff --git a/docs/production/security-model.md b/docs/production/security-model.md index f2bded5510..af55048687 100644 --- a/docs/production/security-model.md +++ b/docs/production/security-model.md @@ -99,26 +99,26 @@ strength allowed is controlled by two settings in parser which escapes content to protect against cross-site scripting attacks. -- Zulip supports both public streams and private streams. +- Zulip supports both public channels and private channels. - - Any non-guest user can join any public stream in the organization, - and can view the complete message history of any public stream - without joining the stream. Guests can only access streams that + - Any non-guest user can join any public channel in the organization, + and can view the complete message history of any public channel + without joining the channel. Guests can only access channels that another user adds them to. - Organization owners and administrators can see and modify most - aspects of a private stream, including the membership and + aspects of a private channel, including the membership and estimated traffic. Owners and administrators generally cannot see - messages sent to private streams or do things that would + messages sent to private channels or do things that would indirectly give them access to those messages, like adding members - or changing the stream privacy settings. + or changing the channel privacy settings. - - Non-admins cannot easily see which private streams exist, or interact - with them in any way until they are added. Given a stream name, they can - figure out whether a stream with that name exists, but cannot see any - other details about the stream. + - Non-admins cannot easily see which private channels exist, or interact + with them in any way until they are added. Given a channel name, they can + figure out whether a channel with that name exists, but cannot see any + other details about the channel. - - See [Stream permissions](https://zulip.com/help/stream-permissions) for more details. + - See [Channel permissions](https://zulip.com/help/stream-permissions) for more details. - Zulip supports editing the content and topics of messages that have already been sent. As a general philosophy, our policies provide @@ -143,21 +143,21 @@ strength allowed is controlled by two settings in and bots. - Owners and administrators have the ability to deactivate and - reactivate other human and bot users, archive streams, add/remove + reactivate other human and bot users, archive channels, add/remove administrator privileges, as well as change configuration for the organization. Being an organization administrator does not generally provide the ability to read other users' direct messages or messages sent to private - streams to which the administrator is not subscribed. There are two + channels to which the administrator is not subscribed. There are two exceptions: - Organization owners may get access to direct messages via some types of [data export](https://zulip.com/help/export-your-organization). - Administrators can change the ownership of a bot. If a bot is subscribed - to a private stream, then an administrator can indirectly get access to - stream messages by taking control of the bot, though the access will be + to a private channel, then an administrator can indirectly get access to + channel messages by taking control of the bot, though the access will be limited to what the bot can do. (E.g. incoming webhook bots cannot read messages.) @@ -181,7 +181,7 @@ strength allowed is controlled by two settings in you should rotate the user's Zulip API key. - Guest users are like Members, but they do not have automatic access - to public streams. + to public channels. - Zulip supports several kinds of bots with different capabilities. @@ -192,7 +192,7 @@ strength allowed is controlled by two settings in notifications, or create other bots). - Bots with the `can_forge_sender` permission can send messages that appear to have been sent by another user. They also have the ability to see the names of all - streams, including private streams. This is important for implementing + channels, including private channels. This is important for implementing integrations like the Jabber, IRC, and Zephyr mirrors. These bots cannot be created by Zulip users, including diff --git a/docs/production/troubleshooting.md b/docs/production/troubleshooting.md index a46af72bd3..6d27dee330 100644 --- a/docs/production/troubleshooting.md +++ b/docs/production/troubleshooting.md @@ -8,7 +8,7 @@ provide free, interactive support for the vast majority of questions about running a Zulip server. To report a problem or ask a question, please start a new topic in the -[#production help][production-help] stream in the [Zulip development community +[#production help][production-help] channel in the [Zulip development community ][chat-zulip-org]: - Describe what you are trying to do and any problems you've encountered.