We now allow only content edit in message_edit_form which can
be opened by pencil icon in the message row, "Edit message"
option in popover and by using e hotkey.
As a result of this change, we also do not show topic and stream
edit options when using "View source" options.
We would instead support changing stream and topic from the modal
which will be opened from the "Move message" option in message
actions popover.
Previously we did not send notification for topic-only edits.
Now, we add backend support for sending notification to topic-only
edits as well.
We would add support for this in webapp in further commits since
message edit UI will be updated as well. We just make sure that no
notifications are sent when editing topic using pencil icon in
message header.
We also change the API default for moving a topic to only notify the
new location, not the old one; this matches the current defaults in
the web UI.
Includes many tests.
We also update the puppeteer tests to test only content edit as
we are going to change the UI to not allow topic editing from
message edit UI. Also fixing the existing tests to pass while
doing topic edits is somewhat complex as notification message
is also sent to new topic by default.
Fixes#21712.
Co-authored-by: Aman Agrawal <amanagr@zulip.com>
Co-authored-by: Tim Abbott <tabbott@zulip.com>
We want to be able to differentiate between the stream and the topic
in the title bar, but the current implementation displays both the
steam name and the topic name in the same way which becomes difficult
to comprehend at a glance.
In this commit, we make the following changes,
- <stream_name> to #<stream_name> (when viewing the entire stream)
- <topic_name> to #<stream_name> > <topic_name> (when viewing a topic)
These changes help us differentiate between a stream and a topic with
with a quick glance.
Fixes#22969.
"Add a new bot" tab from personal `settings > bots` moving this
into a modal form, so we can trigger this form from other places
too without duplicating the code.
Fixes part of #20309.
This may have originally made sense as a class that managed the
browser state, but it has since turned into a dumping ground for
mostly pure functions that don’t make sense to instantiate.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
The reason for the flake was we were not waiting enough
time for the dropdown to render search results when we
type `rome`
To fix this, We are waiting until the dropdown input value
evaluates to be `rome`.
We also update variable name from
`verona_in_dropdown` to correct `rome_in_dropdown`.
Fixes#21716.
By allowing users to view drafts that are addressed to their current narrow,
we hope to help them more easily find and continue previously drafted
messages.
The reason for the flake was we were not waiting enough
time for the deactivation row to render.
To fix this, We are relying on the input from the user
deactivation screen to focus.
The reason for the flake was we were not waiting for the
settings modal to open completely.
To fix this we now wait until the profile tab is focused to
detect if the settings modal is open completely (i.e ready
for the interaction).
The issue with the existing code is that we use the
`page.waitForSelector` function to detect if the element
is visible and interactable.
`page.waitForSelector` only ensures that the element is
visible and doesn't guarantees that the element is
interactable. Most of the time it is enough but sometimes
it is too fast and our test fails.
To fix this we change our approach to check the button
text on the stream settings page (`/#streams/stream_id`).
Either it could be `Subscribe` or `Unsubscribe`.
It was introduced in
56b2b838ee commit.
It fixes `test_narrow_public_streams` test which checks
that, there are no bookends in ` /streams/public`. The
issue was there were no bookends by default when we
were checking in the Denmark stream. We fix this by
unsubscribing from the Denmark stream which will
create a bookend.
This allows this component to follow existing design patterns, rather
than being its own unusual element with various quirks.
The implementation is approximately the same as before I just migrated
"Edit custom profile field" form into modal, like "Add new custom
profile field" form modal.
Fixes: #21634
This lets us remove this fairly ugly user interface widget, which was
inconsistent with the rest of the settings UI.
The implementation is approximately the same as before I just migrated
"Add new custom profile field" form into a modal, status update
notifications about these forms will be displayed inside their modal,
and made some little design changes as discussed on CZO.
Fixes part of: #21634
Change submit button text of both bot and user deactivation confirm
modal from "Confirm" to "Deactivate".
Calling `launch()` function from `dialog_widget.js` because
`confirm_dialog.js` set submit button text to "Confirm".
Set the default_language as cookie and reload the page so that
the spectator can immediately see the language change in effect.
We can reload the page forcefully for spectators since there is
no chance of any work being lost. It is possible that the spectator
may lose the selected message on doing so.
This requires a new dependency, to be able to set cookies from
frontend JavaScript.
Fixes#21961
In settings, clicking on deactivate bot button will lead to open
confirmation modal, and displaying all status update notifications
inside this confirmation modal.
This commit is a follow-up of zulip#21490.
The changes in the last few commits changed the semantics of the
organization default language to no longer be the primary source of
information for a user's language when creating a new account.
Here, we change the settings UI and /help/ documentation to reflect
this.
The implementation closely follows `handle_deactivation()`.
Using the same existing reactivate confirmation modal.
Also, this commit will also lead to open confirmation modal
to reactivate bots in settings > bots, and currently there is no
existing confirmation modal for deactivating bots.
This commit is a follow-up of #21436.
Doing these in a loop may help us figure out whether the
flakes are somehow related to the initial conditions when
we run the test vs. some race that can happen later in the
loop.
I add the console statements mostly to facilitate debugging,
but they appear to actually reduce the problem, as the code
comments indicate.
We have a flake related to verifying that the app
prevents us from creating stream with duplicate names,
and my hypothesis is that it has to do with us not
waiting for the stream creation UI to fully appear. This flake
is probably a consequence of us recently making the stream
creation UI more like the stream editing UI, and thus
waiting for Desdemona to appear was giving us false
confidence that the page actually loaded.
I could be completely wrong about this solving the
flake, but the code change here is sensible regardless.
The most notable change here is that when you are adding
subscribers to a stream as part of creating the stream,
you can now use the same essential pill-based UI for
adding users as we do when you edit subscribers for an
existing stream.
We don't try to exactly mimic the edit-stream UI or
implementation, since when you are adding subscribers
during create-stream, we are just updating a list in
memory, whereas in the edit-stream UI, we immediately
send info to the server.
Fixes#20499
353d0f9 removed this test as it was causing alert words test
fail non-deterministically. See 353d0f9's commit message for
some more details.
Rearranging the order to make this test run in the end can
eliminate the non-deterministic failures due to this test.
Because we reset the test database in between test files, we don't
expect there to be any issues with test files running after this.
Changing the password seems to randomly cause one of
our calls to /json/events to return a 401.
The symptom of this is that when you update alert words,
we don't get the event, and the alert words list does
not get updated.
More context here:
https://chat.zulip.org/#narrow/stream/43-automated-testing/topic/alert.20word.20flakes/near/1334824
It is possible that this reflects an actual problem in
our system when you update passwords.
For now, though, the goal is simply to make this test
reliable, so that we don't have to chase down this flake
any more. It was a particularly tricky flake to debug,
since the alert words test really wasn't at fault here.
It's plausible that we don't want to have the app declare
success when the server acks an alert word POST, and the
app should instead wait for the event to come back before
giving any confirmation to the user.
Since we do not allow to remove owners from bots, it is better
to keep owners for the bots in development environment as well.
We need to change puppeteer tests here because now desdemona
already has bots in dev server and thus "Active bots" section
is opened by default in the settings instead of "Add a new bot"
section.
Sahil Batra
Julia Bichler
sayamsamal
Ganesh Pawar
Yogesh Sirsat
Anders Kaseorg
Riken Shah
Ganesh Pawar
evykassirer
Tim Abbott
Adam Sah
Aman Agrawal
Steve Howell
Dinesh
NerdyLucifer