When 'resolve|unresolve' and 'change topic' actions occurs in
the same api call using 'topic sidebar icon', only 'topic_moved'
notification is sent.
Both 'topic moved' and 'topic resolved' notification should be generated.
Currently, 'select_stream_id' is not set to 'undefined',
even if we only change 'topic name' and/or 'resolve|unresolve' topic.
Resulting in no 'resolved_topic' notification.
This commit sets 'select_stream_id' to 'undefined' to fix the issue.
On updating the stream from the dropdown menu in the move-messages popover,
the confirm button is enabled. On changing the stream back to the initial
value, doesn't disable the confirm button. It can result in the
creation of infinite notifications.
On stream update, 'update_submit_button_disabled_state()' doesn't receive
'stream_id' as a parameter, resulting in 'undefined' stream_id,
'button.disabled' is always set to false after the first update.
This overrides the settings in the web interface, and enables much
more flexible configuration of the build environment (which previously
defaulted to Python 3.7).
https://docs.readthedocs.io/en/stable/config-file/v2.html
Signed-off-by: Anders Kaseorg <anders@zulip.com>
The banner telling the user to scroll down to the message previously
didn't disappear when the user scrolled past it manually, which is
not ideal.
Keep track of which message is associated with this notification,
and clear the banner when the message scrolls above the bottom of
the viewport.
Previously the message would disappear after 300ms, but it can be
annoying for a useful link to disappear so quickly like that.
This commit removes that logic. Now the banner is closed only when
the user explicitly closes it or clicks on the link.
Note that the banner doesn't go away if the user manually scrolls
down. I still think this change is overall better, but if there's
an easy way to add that as well we should do it!
Fixes part of #19857.
This notification ("scroll down to view your message" with a link
for the user to click to scroll down) was added in e2c388c and
removed in 657e1f1 in a commit almost immediately afterwards.
Later the notification was added again, but there was notably no
link to scroll, just the message to scroll down. 372cb20
The link to scroll down was "added" in 1a63c2d when it was fixing
a similar link in another notification. But the implementation
didn't actually use the link (because there was no classname passed
through).
This commit adds a classname so that the link is clickable by
the user.
Fixes part of #19857.
This adds a new endpoint /jwt/fetch_api_key that accepts a JWT and can
be used to fetch API keys for a certain user. The target realm is
inferred from the request and the user email is part of the JWT.
A JSON containing an user API key, delivery email and (optionally)
raw user profile data is returned in response.
The profile data in the response is optional and can be retrieved by
setting the POST param "include_profile" to "true" (default=false).
Co-authored-by: Mateusz Mandera <mateusz.mandera@zulip.com>
This will be useful for re-use for implementation of an endpoint for
obtaining the API by submitting a JWT in the next commits.
It's not a pure refactor, as it requires some tweaks to remote_user_jwt
behavior:
1. The expected format of the request is changed a bit. It used to
expect "user" and "realm" keys, from which the intended email was
just generated by joining with @. Now it just expects "email"
straight-up. The prior design was a bt strange to begin with, so this
might be an improvement actually.
2. In the case of the codepath of new user signup, this will no longer
pre-populate the Full Name in the registration form with the value
from the "user" key. This should be a very minor lost of
functionality, because the "user" value was not going to be a proper
Full Name anyway. This functionality can be restored in a future
commit if desired.
This is an API change, but this endpoint is nearly unused as far as
we're aware.
The image preview in the 'upload_widget' would scale images that are
wider than the intended square shape for custom emoji; this resulted
in a misleading preview, because the server will instead crop such
images to take their leftmost square.
Fix this using 'object-fit: cover', to have the browser do something
similar.
Previews of the current bot avatar and the uploaded bot avatar were not
displayed during bot creation or editing.
We address this by extending The 'upload_widget' component with with
'preview_text' and 'preview_image' parameters to provide a preview of
the image that will be used as the bot's avatar during bot creation or
editing.
Fixes#23023.
- Updates `.prettierignore` for the new directory.
- Updates any reference to the API documentation directory for
markdown files to be `api_docs/` instead of `zerver/api/`.
- Removes a reference link from `docs/documentation/api.md` that
hasn't referenced anything in the text since commit 0542c60.
- Update rendering of API documentation for new directory.
Moves the check for calling the `api-doc-template.md` directly,
so that we don't return a 500 error from the server, to happen
earlier with other checks for returning a 404 / missing page.
Also adds a specific test to `zerver/tests/test_urls` for this
template.
Prep commit for moving API documentation directory to be a top
level directory.
- Clean up the language.
- Add a prominent "Go to organization" button.
- Link to guides for new users and admins.
- Fix duplication bug in text email version.
Co-authored-by: Mateusz Mandera <mateusz.mandera@zulip.com>
Black 23 enforces some slightly more specific rules about empty line
counts and redundant parenthesis removal, but the result is still
compatible with Black 22.
(This does not actually upgrade our Python environment to Black 23
yet.)
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This links users or bots in Stream settings -> Subscribed users, to
their respective user profile card.
Also, changes were made to close any active overlay, on clicking any of
the PM buttons in the user profile card. This help us avoid writing
separate conditions for multiple overlays, like settings overlay or
stream settings overlay.
Fixes part of #18880.
Due to some quirks of CSS specificity, a rule for 0 `right-padding` was
overriding a rule for 2px `right-padding` for topic names.
This is now corrected, and the padding increased to 3px for a less
cramped look, for PMs, topics and streams. Repetition of CSS has also
been removed.
The commit af36e9f added a bug that breaks new user invite.
The CSS class ` bootstrap-focus-style` was added to `id`,
hence breaking the value extraction.
Fixes: #24249
We override the bottom margin added by bootstrap for
url type custom profile input in user profile page
and all the inputs in edit-user form. Previously, this
was handled by form-horizontal class which was removed
in #24057.
For most of the other text-type inputs, it is overridden
in app_components.css and for checkbox-type inputs, it is
overridden by other bootstrap CSS itself. But that only
handles text-type and checkbox-type inputs inside
".new-style" element and not url type inputs.
Some other inputs already have specific CSS to override the
bootstrap CSS.
For the same reason, there is no need to override bottom
margin for inputs in organization profile as there is no
url type inputs in that page and this commit removes the
CSS for it.
Creates a shared `disabled_setting_tooltip` class that can be
reused in cases where a personal or organization setting button
or input is disabled and a tooltip is added to give information
about why the user cannot change/access the setting.
Changes `name-input` class, that was only being used in a div
wrapper for the input element for changing a user's full name,
to be a more specific id name: `full_name_input_container`.
This id is used to set or remove the disabled setting tooltip
when name changes are disabled by the organization.
There are no CSS rules set with this class/id.
The `pg_upgrade` tool uses `pg_dump` as an internal step, and verifies
that the version of `pg_upgrade` is the same exactly the same as the
version of the PostgreSQL server it is upgrading to. A mismatch (even
in packaging versions) leads to it aborting:
```
/usr/lib/postgresql/14/bin/pg_upgrade -b /usr/lib/postgresql/13/bin -B /usr/lib/postgresql/14/bin -p 5432 -P 5435 -d /etc/postgresql/13/main -D /etc/postgresql/14/main --link
Finding the real data directory for the source cluster ok
Finding the real data directory for the target cluster ok
check for "/usr/lib/postgresql/14/bin/pg_dump" failed: incorrect version: found "pg_dump (PostgreSQL) 14.6 (Ubuntu 14.6-0ubuntu0.22.04.1)", expected "pg_dump (PostgreSQL) 14.6 (Ubuntu 14.6-1.pgdg22.04+1)"
Failure, exiting
```
Explicitly upgrade `postgresql-client` at the same time we upgrade
`postgresql` itself, so their versions match.
Fixes: #24192
Removes `base_path` argument when making the markdown extension for
parameters in documentation for API endpoints.
This seems to have been originally included for API parameters that
were documented in JSON files, which is no longer in use. Now all
API endpoints in the documentation are documented in
`zerver/openapi/zulip.yaml`.
Removes `base_path` argument when making the markdown extension for
return values in documentation for API endpoints.
This seems to have been a copy and paste error in commit d2ee99a2fd
when `zerver/lib/markdown/api_return_values_generator.py` was created.
Until now, custom emojis with "periods" in their name were allowed, even though
they don't really fit the pattern of how we name them, and in fact the Markdown
processor would not render such custom emoji. Fix this by just disallowing the
character.
Also update the error strings accordingly.
Note that this does not include a migration to eliminate any existing custom emoji with this
character in their name.
Fixes#24066.
This fixes a very noticable regression in
92788a52bb, where using Up/PageUp/Home
when focus was in anything other than the compose box would
incorrectly be treated as message feed navigation.
Fix this by adding a new check, but this now has some fairly
duplicated code that queries the DOM for the same thing 3 times in a
row; added a TODO comment explaining a likely better approach.
When a realm emoji overrides a default emoji, `:emoji_name:` now renders
as the realm emoji. Still, the typeahead menu would misleadingly show
the now overridden default emoji for the same name. Selecting it would
render as the realm emoji, which is very confusing user experience.
Now when selecting the emojis to suggest in the typeahead, the overridden
default emojis are excluded.
Fixes part of #24120.