- Add a step to update the bot's API key if using a generic bot
for bidirectional bridging.
- Clarify setup options for how Slack channels are mapped.
- Edit for clarity and succinctness.
This commit adds support to display `Message.EMPTY_TOPIC_FALLBACK_NAME`
value (translated) in the missedmessage email body and subject for
topics having the actual value of empty string.
Fixes part of #32996.
Previously, 'check_update_message' allowed moving messages to
empty topic even with `mandatory_topic=true`.
This commit fixes the bug. We now raise an error in that case.
Co-authored-by: Prakhar Pratyush <prakhar@zulip.com>
In the profile card that pops up when clicking a user's name,
the text of their name was not selectable text previously.
This commit makes the text selectable.
Earlier, in 'topic_list_data.ts' we were using 'topic_display_name'
variable to represent part of the topic name without resolved_prefix.
This could led to confusion with 'util.get_final_topic_display_name()'
as both represent different things.
This commit updates the code to use 'topic_bare_name' for a better
representation of its meaning.
We've added a comment highlighting that the function does not check
whether a user has access to the channel or not. Adding `accessible` to
the function name further emphasises that.
The code will behave the same before and after this commit, what this
commit helps in is readability. By adding
`enable_or_disable_add_subscribers_elements`, we will no longer be
confused as to why that function appears in stream_edit and not in
stream_create.
Rename `can_subscribe_others_to_all_streams` to
`can_subscribe_others_to_all_accessible_streams` so it's clear that we
are not attempting to check basic access in this function.
These characters cause the fallback markdown
links produced (#30071) to be broken.
Broken links are not produced when these are present
in `#**channel>topic**` syntax. It is only a problem
with the fallback markdown links.
value can be None when property is jitsi_server_url,
message_content_edit_limit_seconds,
message_content_delete_limit_seconds,
move_messages_between_streams_limit_seconds, or
move_messages_within_stream_limit_seconds.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Fixes#32369
Migrate stream delete event to include only stream ids in the form of
"stream_ids": [1,...], because clients only need the ids.
While keep sending ids in the form of "streams": [{stream_id: 1},...]
for compatibility with all clients other than web.
This commit updates embedded bots to mark messages they have process as
read. Since the service bots have their own `UserMessage` rows, this
change enables us to track whether the bot has in fact processed the
message by adding the `read` flag to their `UserMessage`.
Fixes#28869.
This commit updates outgoing bots to mark messages they process as read.
Since the service bots have their own `UserMessage` rows, this change
enables us to track whether the bot has in fact processed the message by
adding the `read` flag to their `UserMessage`.
Previously, service bots don't get UserMessage rows for new messages to
optimize performance. This commit adds UserMessage row for service bots
so that they behave more similarly to generic bots.
The current `get_migration_by_app` has a rather naive approach to
compiling the migration status of a realm, which has led to issues like
#32826. Specifically, those flaws are:
- it does not report the complete state of the migration status of the
exporting servers, only the applied migration.
- it shows both the replaced and the squashed migrations. This would be
a problem if we decide to clean up old migration files we've
squashed(replaced) and import a slightly older realm with those still in
disk. `check_migration_status` would complain of incompatibility even
though those migration files don't matter (they are replaced, after
all).
- it does not clean up ancient/stale applied migrations (for reference,
see how `check-database-compatibility` cleans those)
This commit attempts to write a better `migration_status.json` by
parsing the output of `showmigrations` instead.
This is because Django's `showmigrations` has a lot more logic and
validations baked into it than previously thought. Ones that we care
about are:
- it does validations to make sure app names are valid
- it doesn't list replaced migrations and only squashed one
- it takes into account migrations in disk(`MigrationsLoader`) vs
applied migrations (`MigrationsRecorder`)
Which would resolve the first two points highlighted above.
This commit adds `parse_migration_status`, which takes in the string
output of `showmigrations` and parse it into key-value pair of installed
apps and a list of its migration status.
This is a prep commit to rework the check migrations function of
import/export which will parse the output of `showmigrations` to write
the `migration_status.json` file.
This consolidates the list of stale migration to
`lib/migration_status.py` as `STALE_MIGRATIONS`.
This is a prep work to make the migration status tool at
`migration_status.py` be able to clean its output of these migrations
too.
Currently if for what ever reason one decided to change how
`migration_status.json` is written, the check migrations tests in
`test_import_export.py` will happily just use the old and potentially
stale migration status test fixtures in
`fixtures/applied_migrations_fixtures` against other stale fixtures and
run the check migrations tests in a bubble.
This adds an assertion in `verify_migration_status_json` that makes sure
all the migration status fixtures we use in the tests resembles the
actual `migration_status.json` file our export tool will write.
in `get_migrations_status`, we clean up the printed output of any ANSI
codes used to format the output. Currently the regex only cleans up bold
ANSI escape code (\x1b[1m) and style reset code (\x1b[0m). So it won't
be able to clean up basic ANSI escape codes such as "\x1b\31;1m" which
is used to format `showmigrations` output for apps with no migrations.
e.g, "\x1b\31;1m (no migrations)"
This commit updates the regex to catch a wider range of basic ANSI
codes.
The `get_migration_status` command calls `connections.close_all()` when
its done and it was previously only called when we need to rebuild the
dev or test database and when running the `get_migration_status`
command.
This commit moves the `connections.close_all()` call out of the function
and into `test_fixtures.py` directly, making sure it will only be called
when we are rebuilding the dev/test database. This is a prep work to
refactor the check migration function of import/export later on which
plans to use `get_migration_status`.
This moves `get_migration_status` to its own file in
zerver/lib/migration_status.py. This is a prep work to refactor the
check migration function of import/export later on.
Some of the imports are moved into `get_migration_status` because we're
planning to share this file with `check-database-compatibility` which is
also called when one does `production-upgrade`, so we'd want to avoid
doing file-wide import on certain types of modules because it will fail
under that scenario.
In `test_fixtures.py`, `get_migration_status` is imported within
`Database.what_to_do_with_migrations` so that it is called after
`cov.start()` in `test-backend`. This is to avoid wierd interaction with
coverage, see more details in #33063.
Fixes#33063.
1. Fetching from the `/users.list` endpoint is supposed to use
pagination. Slack will return at most 1000 results in a single
request. This means that our Slack import system hasn't worked
properly for workspaces with more than 1000 users. Users after the
first 1000 would be considered by our tool as mirror dummies and thus
created with is_active=False,is_mirror_dummy=True.
Ref https://api.slack.com/methods/users.list
2. Workspaces with a lot of users, and therefore requiring the use of
paginated requests to fetch them all, might also get us to run into
Slack's rate limits, since we'll be doing repeating requests to the
endpoint.
Therefore, the API fetch needs to also handle rate limiting errors
correctly.
Per, https://api.slack.com/apis/rate-limits#headers, we can just read
the retry-after header from the rsponse and wait the indicated number
of seconds before repeating the requests. This is an easy approach to
implement, so that's what we go with here.
Because button sizes are precisely specified in the area, we set
the buttons as flex items that neither to grow or shrink, which
is essential to right-size the button area for the help button.
Fixes#32199
We only need a log in button since that will take users to
"/accounts/go" if we are on a non-realm specific URL.
"/accounts/go" already has link to go to "Find accounts" page.
This commit moves get_realm_user_groups_for_setting and
get_realm_user_groups_for_dropdown_list_widget functions
from user_groups.ts to group_permission_settings.ts.
This change is needed to avoid import cycles in further
commits to add "Permissions" panel for groups.
