Adds documentation for admins to manage users via the user profile
modal for these actions:
- Deactivating a user
- Changing a user's role
- Changing a user's name
Creates two new tab sections because we still want to document
the ability to do these actions through the users section in
the organizational settings modal.
Also cleans up some text in the help center article for changing
a user's role.
Fixes#21318.
Fixes#21415.
Cleans up the list of actions that can be restricted via settings
for new members. Previously, there were a number of entries in the
list that began with 'Restricting' and not the action that was
being set.
Adds content on user group permissions / management to the general
help center article for user groups (`/help/user-groups`) and
removes the then redundant `/help/restrict-user-group-management`
article.
Redirects links in help center and api documentation from deleted
article to the new configure user group settings section of
`/help/user-groups`.
Fixes#21383.
Extends existing documentation about user status to cover
both potential parts of a status: emojis and messages.
Also, adds a link in the `/help/web-public-streams` article
where user status is referenced.
Fixes#21369.
Adds a section to the typing notifications documentation about
how to disable them in as a personal privacy setting.
Extended by tabbott to explain the setting in more detail.
Fixes#21381.
As the different settings are described in the help center doc
for creating a new stream, we need to update the final setting
name from 'People to add' to the new 'Choose subscribers' that
is in the UI.
Also, updates that setting description to include adding users
via user groups or the new add all users option.
Extends the documentation on unsubscribing users from streams to
include an alternate method via the user's full profile, which
is useful for cases where admins may need to unsubscribe a single
user from multiple streams.
Fixes#21379.
Previously, this URL just returned the `raw_content` field. It seems
cleanest to just make it a single-message variant of GET /messages,
deprecating the only format.
The header was more confusing than helpful, and we
want the create-stream UI to be less cluttered.
We don't really need the help-center text here, since
we already have ? icons next to the relevant headings
for the sub-sections.
We kill off some CSS, but we won't kill off stream-title
until the big upcoming changes for stream pills.
Since we've changed the database to contain these new fields, we just
need to stop dropping them in the API code.
This also changes the public API to match the database format again
by removing `prev_subject` from edit history API.
Adds an API changelog feature update for the renamed `prev_subject`
field (to `prev_topic`) and new fields (`topic` and `stream`)
in the message `edit_history`.
Also, documents said `edit_history` in the `MessagesBase` schema
in the api documentation, which is used by the `/get-messages`,
`/get-events` and `/zulip-outgoing-webhooks` endpoints.
Fixes#21076.
Co-authored-by: Lauryn Menard <lauryn.menard@gmail.com>
The database value for expiry_date is None for the invite
that will never expire and the clients send -1 as value
in the API similar to the message retention setting.
Also, when passing invite_expire_in_days as an argument
in various functions, invite_expire_in_days is passed as
-1 for "Never expires" option since invite_expire_in_days
is an optional argument in some functions and thus we cannot
pass "None" value.
Adds a section about the Markdown feature to auto-link to
existing streams and topics in a Zulip message.
Also, does a little reformatting of existing text/tabs and
adds a related links section to the page.
Fixes#21085.
Co-authored-by: Alya Abbott <alya@zulip.com>
Adds `realm_web_public_access_enabled` as a realm-specific server
setting potentially returned by the `/get-server-settings` endpoint
so that clients that support browsing of web-public stream content
without an account can generate a login page that supports that
type of access.
Notifies user when messages are not being marked as read through a
banner that lets them mark all messages in the narrow as read. Note
that the banner is only displayed if the user's actions, like
scrolling, would've actually marked the messages as read.
This avoids distracting the user when viewing a thread they've already
read.
tabbott has verified that if new messages come in, the banner will reappear.
Fixes: #18768.
The previous explanation of generic bots was inaccurate.
This page needs a lot more cleanup, but this at least fixes the
clearest inaccuracies.
Fixes#19978.
Lauryn Menard
Alya Abbott
Aman Agrawal
Steve Howell
Tim Abbott
Lauryn Menard
Sahil Batra
Anders Kaseorg
rht
Dinesh
kraktus
jai2201
Alex Vandiver