As they stand now, alert words tests will cause a race condition with
all subsequent tests which access the UserProfile object these tests
modify. Currently, if we modify alert words, we don't get any
notification from the server, issue reported at #1269. Consequently, we
can't wait on any condition to avoid the race condition. The best option
is to wait for the fix of #1269 and modify the tests in that issue.
Fixes: #1244
There is a hard to reproduce race condition causing these tests to
occasionally fail. We believe it is caused by switching to the home tab and
not properly waiting for all the messages to load; see Issue #1243. The
tests are for the following pathway (not a high priority to test):
1. User starts editing a message.
2. allow_message_editing is turned off for the realm (in this case, by the
user going to the admin page and turning it off).
3. User finishes editing the message and hits send.
This is controlled through the admin tab and a new field in the Realms table.
Notes:
* The admin tab setting takes a value in minutes, whereas the backend stores it
in seconds.
* This setting is unused when allow_message_editing is false.
* There is some generosity in how the limit is enforced. For instance, if the
user sees the hovering edit button, we ensure they have at least 5 seconds to
click it, and if the user gets to the message edit form, we ensure they have
at least 10 seconds to make the edit, by relaxing the limit.
* This commit also includes a countdown timer in the message edit form.
Resolves#903.
There is a hard to reproduce race condition causing these tests to
occasionally fail. We believe it is caused by switching to the home tab and
not properly waiting for all the messages to load; see Issue #1243. The
tests are for the following pathway (not a high priority to test):
1. User starts editing a message.
2. allow_message_editing is turned off for the realm (in this case, by the
user going to the admin page and turning it off).
3. User finishes editing the message and hits send.
This is controlled through the admin tab and a new field in the Realms
table. This mirrors the behavior of the old hardcoded setting
feature_flags.disable_message_editing. Partially resolves#903.
We originally waited for .message_edit_notice to appear, now we wait for
textarea.message_edit_content to disappear.
This is better because the previous code didn't correctly handle
editing the same message twice (the "EDITED" tag would still be there
from the first edit, so it wouldn't wait at all the second time!).
Assigns hotkey 'w' to search streams.
Only show search box when active. Activate with hotkey or by clicking
STREAMS.
Filter matches at the beginning of words in stream name.
Behaviour is otherwise almost identical to user search.
Casper tests.
We only use zxcvbn in the main webapp for checking the user's password
in the change password form. Since zxcvbn is a very large javascript
library (~700KB), loading it asynchronously only when a user is trying
to change their password results in a significant performance
improvement for loading the Zulip webapp on a slow network.
Fixes#263.
* The warning contains a count of the number of people in the stream.
* An error appears if the warning is ignored and the user tries to
send the message anyway.
* The message cannot be sent until the warning is acknowledged or @all
/ @everyone is removed.
* This only applies to stream messages and not private messages.
Fixes#853.
Previously, we were checking if a particular user was the current user
in dozens of places in the codebase, and correct case-insensitive
checks were not used consistently, leading to bugs like #502.
Since relatively few systems have the typing module, this makes the
checks for whether the user is properly running our test scripts in
the virtualenv more likely to trigger well.
This should make users much more likely to be able to debug issues
where they ran Zulip outside the Vagrant environment or virtualenv.
[error messages tweaked by tabbott]
.message_edit_notice is too broad of a selector to
test if your most recent edit has posted. Also
check if the currently selected message is the one
that's been edited.
When you deactivate a user, visit another page, and then
come back, the user shows up in another table (the
"Deactivated Users" table), and no longer has the
strikeout styling of a recently deactivated user.
Using the strikeout class as a selector to test if the
user has been reactivated will of course not be a good
test, and if you have a slow machine, lose a
race condition.
When you deactivate a user, visit another page,
and then come back, the user shows up in another
table, and no longer has the strikeout styling
of a recently deactivated user. Using strikeout
class to test if the user has been reactivated
will of course not be a good test, and if you
have a slow machine, lose a race condition.
Tim Abbott
Taranjeet Singh
Umair Khan
Rishi Gupta
Rishi Gupta
Preston Hansen
Steve Howell
Tomasz Kolek
Kartik Maji
Alex Wilson
Aakash Tyagi
Vishnu Ks
Michael Cordover
James Porter
Caroline Liu
Givorenon
Ernesto Vargas
acrefoot
Eklavya Sharma