Previously notifications.clear_compose_notifications was used accross
the codebase. Since introducing the new
compose_banner.clear_message_sent_banners function, the two functions
are similar enough that we can just use clear_message_sent_banners
everywhere. This commit also moves scroll_to_message_banner_message_id
to compose_banner.
This is a prep commit for redesigning this banner. The
change from `note` to `banner_text` is more consistent
with `compose_banner`. `link_class` is renamed to classname
and will be used for the banner a whole and not the link
class anymore, which is why the check for displaying a link
now looks to see if `link_text` is defined instead.
This has been present since this modal was first introduced in
b9098a42d4, but as far as I can tell, it
has never been correct. We know `old_topic_name` is not
null/undefined, since we do a check with it trimmed earlier in the
function, and there is no product reason why we would would to
silently fail to move a topic because its name was the empty string.
When 'resolve|unresolve' and 'move stream' actions occurs in
the same api call, 'This topic was marked as resolved|unresolved'
notification is not sent.
Both 'topic moved' and 'topic resolved' notification should be generated.
This commit updates the logic of when and where to send
'topic resolve|unresolve' notification. Unlike previous logic, notification
may be sent even in the case 'new_stream' is not None.
In general, 'topic resolved|unresolved' notification is sent to
'stream_being_edited'. In this particular case ('new_stream' is not None),
notification is sent to the 'new_stream' after check.
Test case is included.
Fixes: #22973
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.
evykassirer
Joelute
Anders Kaseorg
Tim Abbott
Prakhar Pratyush
Alessandro Toppi
Mateusz Mandera
Sahil Singh
Aman Agrawal
Brijmohan Siyag
Lauryn Menard
Alya Abbott
Alex Vandiver
Ganesh Pawar
SameepAher
N-Shar-ma
Sahil Batra
Prashant Vithani