* Created a drafts modal to display/restore/delete drafts
* Created a Draft model to support storing draft data in localstorage
* Removed existing restore-draft functionality
* Added casper and node tests for drafts functionality
Fixes#1717.
For our user administration, we now primarily work with user ids
that get put into data-user-id attributes. We still put emails in the
tags to make our Casper tests easy to maintain.
This requires a minor change to the back end to pass down user ids
for the /users endpoint (in get_members_backend).
I dug into why we never did this before, and it turns out we did, but
using `$.trim()` (which removes leading whitespace as well!). When
removing the `$.trim()` usage.
Fixes#3294.
This fixes a potential class of flakiness in the tests where they
interact with parts of the admin UI that aren't actually visible at
the moment via selectors, which probably doesn't test what we intend
to test properly.
For some reason, this section of tests basically totally breaks
whatever test runs after it. To minimize the impact of that problem,
we move it to a separate file.
The casper test file 10-admin.js had gotten to be super huge, so a
split is a good idea regardless, but this should also make quaranteen
for tests broken by the settings redesign more manageable.
This changes the markdown preview test to use the
waitForSelectorTextChange method rather than waitWhileVisible
because it was not being generated fast enough in some cases
to show correctly with waitWhileVisible.
I moved the UI element for "Copy from Stream" to be above
the list of users, including the filter box and check/uncheck
links, which no longer get applied to the list of streams.
The reason I no longer apply the filter to streams is...
* It's kind of confusing to have filters apply to both
streams and users. There should be separate filters for
them, and I will try to resuscitate that feature later.
* The code to filter the streams was doing a sketchy
regex operation against user-inputted data. (`match()`)
* We want to use the same stream filtering code as the
right sidebar uses.
* It improves performance for the common case that you
are filtering users.
The reason I no longer apply the check-all/uncheck-all actions
to streams is that it would be crazy to select all your streams
to copy users from, and it would be expensive/slow for large
realms, and it would likely be done by accident if somebody was
trying to manage individual users.
Finally, the check-all/uncheck-all actions have been scoped
to the users filtered by the text box, so I moved the links
under the text box to make that hopefully more clear to users.
The local echo code now marks up mention buttons with user ids
instead of email. Our code in message_list_view.js deals with
either the old style or the new style of markup now to determine
which mention buttons need to be highlighted.
As part of this commit we extract mention_button_refers_to_me().
When filtering users in the new stream form, check all
and uncheck all will only effect those users who are filtered,
visible in the dom.
Includes a Casper test for the new condition.
This adds some configuration options to settings.py, namely
PASSWORD_MIN_LENGTH and PASSWORD_MIN_QUALITY, which control
when the frontend validator invalidates the password.
Closes#2628
* Doesn't pop up the warning until you actually try to send the message
* Eliminates the red warning.
* Changes confirm text to "Yes, send".
* Adds a stream size threshhold of 15 people; smaller streams don't
prompt about this.
Fixes#2257.
In the new stream creation modal, added checkboxes for each stream
and a toggle to see or hide the checkboxes. Altered filtering to
filter streams and users. Added corresponding casper tests.
When a stream is checked/unchecked, it does not affect the state
of any user checkbox. This may be visually unclear as users can be
added even if their checkboxes are empty.
Fixes#2448
This is a major change to the /#subscriptions page, converting it to
by a side-by-side list of streams and their settings in an overlay.
There are no new features added/removed, but it's a huge changeset,
because it replaces the old navigation logic and moves the stream
creation modal to appear in the right side of this overlay.
Added new option to download .zuliprc file directly from settings
page. This should help reduce friction when setting up new
bots/integrations. This new feature is available in the bot cards and
the 'show your API key' section. One caveat is that the filename is
automatically set to 'zuliprc' instead of '.zuliprc', since as most
browsers do not allow filenames to start with a dot.
Fixes#2327.
* In most cases, eslint --fix with the right comma-dangle settings was
able to update the code correctly.
* The exceptions were cases where the parser incorrectly treated the
arguments to functions as lists/objects and added commas; these are
detectable with linters, and we fixed manually. Since this is test
code, we can be reasonably confident that just fixing the failures
suffices to correct any bugs introduced by making changes
automatically.
Modify backend test of create_streams_if_needed so that the newly
created streams have descriptions.
Modify casperjs test of filling out stream_creation_form so that
the newly created stream has a description.
Fixes: #2428.
Adds a database migration, adds a new string_id argument to the management
realm creation command, and adds a short name field to the web realm
creation form when REALMS_HAVE_SUBDOMAINS is False.
Previously we showed an "Edit" item in the actions popover menu when a user
could edit the content or topic of a message, and nothing otherwise. We now
show "Edit", "Edit Topic", or "View Source" in the popover menu for every
message, depending on the editability of the message, and present an
appropriate version of message_edit_form when the menu item is clicked.
Finishes #1604 and #1761.
Filter behaves similarly to filter in left sidebar, see PR #684. Added
stream input field to the stream creation modal along with other settings,
for clarity.
Fixes#455, #563.
Previously, we sent users to an "invite your friends" page after they
created an organization. This commit removes that step in the flow and sends
users directly to the home page. We also remove the now-unused
initial_invite_page.html template, initial_invite.js (which pre-filled the
invite emails with characters from literature), and the /invite URL route.
This fixes a problem where any absolute redirects in the routes
visited by the Casper tests will cause failures due to switching the
users to a "different" server where the cookies they'd received are no
longer valid.
Now, we at least consistently use the same hostname in the Casper
tests as EXTERNAL_HOST.
These changes prepare us for the casperjs upgrade:
Extract init_viewport().
Have then_log_out() do more explicit waiting.
Add turn_off_press_enter_to_send().
Adds a new field org_type to Realm. Defaults for restricted_to_domain
and invite_required are now controlled by org_type at time of realm
creation (see zerver.lib.actions.do_create_realm), rather than at the
database level. Note that the backend defaults are all
org_type=corporate, since that matches the current assumptions in the
codebase, whereas the frontend default is org_type=community, since if
a user isn't sure they probably want community.
Since we will likely in the future enable/disable various
administrative features based on whether an organization is corporate
or community, we discuss those issues in the realm creation form.
Before we actually implement any such features, we'll want to make
sure users understand what type of organization they are a member of.
Choice of org_type (via radio button) has been added to the realm
creation flow and the realm creation management command, and the
open-realm option removed.
The database defaults have not been changed, which allows our testing code
to work unchanged.
[includes some HTML/CSS work by Brock Whittaker to make it look nice]
I have a hunch that the messages sent from different files
are interfering with each other as well. This commit will make
it clear if indeed this is the case.
This adds support for running a Zulip production server with each
realm on its own unique subdomain, e.g. https://realm_name.example.com.
This patch includes a ton of important features:
* Configuring the Zulip sesion middleware to issue cookier correctly
for the subdomains case.
* Throwing an error if the user tries to visit an invalid subdomain.
* Runs a portion of the Casper tests with REALMS_HAVE_SUBDOMAINS
enabled to test the subdomain signup process.
* Updating our integrations documentation to refer to the current subdomain.
* Enforces that users can only login to the subdomain of their realm
(but does not restrict the API; that will be tightened in a future commit).
Note that toggling settings.REALMS_HAVE_SUBDOMAINS on a live server is
not supported without manual intervention (the main problem will be
adding "subdomain" values for all the existing realms).
[substantially modified by tabbott as part of merging]
This restructures the styling for the Zulip settings and
administration pages to minimize use of Bootstrap and use a consistent
styling library for similar elements.
While it is basically a wash in terms of the page's visuals, it will
make our life a lot easier for future work on improving the settings
pages section of the site.
Chaining together `wait*` functions can create race conditions in the
frontend tests. To avoid race condition, we need to insert `then`
function between two `wait*` functions.
The ‘for’ attribute is not valid HTML in the case of this because the
emails are invalid character sets and the input has no ID with the
email.
This changes it to a data-name which is still searchable but doesn’t
interfere with typical input behavior.
The checkboxes no longer float-left, fixing an issue with the
subscribe buttons leaning right in narrow windows.
Fixes: #1491.
Adds a new field default language in the zerver_realm model.
This realm level default language will be used as default language
for newly created users. Realm level default language can be
changed from the administration page.
Fixes#1372.
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.
Umair Khan
Steve Howell
K.Kanakhin
Sampriti Panda
Tim Abbott
Igor Tokarev
Brock Whittaker
brockwhittaker
polypmer
Bojidar Marinov
Harshit Bansal
Sanskar Modi
Akhil
Rafid Aslam
Tommy Ip
Robert Hönig
AZtheAsian
Calvin Lee
Vladislav Manchev
umkay
Rishi Gupta
hackerkid
trueskawka
Rishi Gupta
Rag Sagar
Kartik Maji
Tim Abbott
Taranjeet Singh
Rishi Gupta
Preston Hansen