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.
Now that we're doing presence updates in a performant fashion, we
don't need to throttle processing these events, and in fact the
throttling of these events created a correctness problem, since we're
now doing incremental updates rather than just rerendering everything
after each event.
Whenever a user became active, this triggers an immediate presence
update event (to show that user as active). The implementation for
that event (running on the browsers of all other users in the realm)
would fully rerender the presence list, which can be an expensive
operation in a large realm, just to update the status for that one
user. This fixes that case to just remove the user from the list and
then re-insert it at the appropriate index.
[Commit message expanded with more details by Tim Abbott]
Like the Stream Subject lists, Private messages are now shown
when the user clicks on the "Private message" link. User can drill in
to get more than 5 conversations. Selecting PMs from the user or group
PM lists on the right sidebar also opens the list & highlights the
selected conversation.
[Edited by tabbott@mit.edu to fix some small bugs.]
The node packages 'jQuery' and 'jquery' are different--'jQuery' is the
legacy support package that is needed for Zulip so the require statements
in the tests were updated.
Travis uses node 4.0 by default and we are using 0.10, so the command to
install the correct version had to be added to the .travis.yml file.
Taranjeet Singh
Eklavya Sharma
Tim Abbott
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
Aristeidis Fkiaras
Vladislav Manchev
Varshit
Kara McNair
Liz Sander
Allie Jones