If a user is narrowed by `is:private`, `pm-with`, or `group-pm-with`,
change the `New topic` button to say `New stream message` instead for
added clarity.
Also, add to the Casper and Node tests for this behavior.
Fix#9072.
One disadvantage of relying on Jinja2 to load all templates is that it
only searches a finite set of pre-configured template directories.
Unfortunately, that breaks when someone tries to enable a custom
privacy or terms page and has the corresponding template in a
directory outside of Jinja2's recognized directories (for instance, it
won't find `/etc/zulip/terms.md`, the recommended path).
This commit makes it so that render_markdown_path can be more
sensible about pure Markdown files and load templates with
absolute paths directly without relying on Jinja2, if need be.
We now update all test messages to have a pub_date
of "now" in the setUp() function in TestRetentionLib.
We've seen tests flake on query counts before this
patch. It's not certain that the test flaked due
to time-related glitches, but it seems the most
plausible explanation.
The "/stats" command doesn't actually do anything
interesting yet, and it also writes to the message
feed instead of replying directly to the user.
The history of this command was that it was
written during a PyCon sprint. It was mainly intended
as an example for subsequent slash commands. The
ones we built after "/stats" have sort of outgrown
"/stats" and don't follow the original structure
for "/stats". (The "/day", "/ping", and "/settings"
commands were built shortly after.)j
We probably want to ressurect "/stats" fairly soon,
after figuring out some useful stats and refining
the UI.
As you can see from this commit, resurrecting the
code here shouldn't be too difficult, but it
may actually be pretty rare that we just translate
slash commands into fleshed out messages.
Since otp_encrypt_api_key only encrypts API keys, it doesn't require
access to the full UserProfile object to work properly. Now the
parameter it accepts is just the API key.
This is preparatory refactoring for removing the api_key field on
UserProfile.
random_api_key, the function we use to generate random tokens for API
keys, has been moved to zerver/lib/utils.py because it's used in more
parts of the codebase (apart from user creation), and having it in
zerver/lib/create_user.py was prone to cyclic dependencies.
The function has also been renamed to generate_api_key to have an
imperative name, that makes clearer what it does.
Now reading API keys from a user is done with the get_api_key wrapper
method, rather than directly fetching it from the user object.
Also, every place where an action should be done for each API key is now
using get_all_api_keys. This method returns for the moment a single-item
list, containing the specified user's API key.
This commit is the first step towards allowing users have multiple API
keys.
The validate_api_key sentence may look a bit confusing since we are
using webhook_bot's email address but default_bot's API key.
At first sight, and without any context on these tests, it may look like
that's just a typo, but we do want it to be like it is right now because
that way the API key used doesn't correspond to the provided email
address (triggering some untested parts of our backend logic).
Due to copyright issues with potentially displaying Apple emojisets on
non-apple devices, as well as iamcal dropping support for the emojione
emojiset (see https://github.com/iamcal/emoji-data/pull/142), we are
dropping (perhaps temporarily) support for allowing users to switch
emojisets in Zulip.
This commit just hides the feature from the user but leaves most of
the infrastructure in place so that in the future if we decide to
re-enable the support we will not need to redo the infrastructure work
(some JS-side code is deleted, mostly because we'll want to re-add the
feature using the do_settings_change infrastructure anyway).
The most likely emoji set to add is the legacy "blobs" Google emoji
set, since it seems popular with some users.
Tweaked by tabbott to remove some additional JS code and update the
changelog.
Choice type of custom field, displays index of selected choice by user
instead of value of choice.
Fix this by parsing choice-type custom field to get field value before
rendering user popover template.
Fixes#10239
Previously, we incorrectly setup the click handler on
create-custom-field-btn each time settings overlay opens, which
executes handler multiple times results in more than one HTTP request
to server for custom field creation.
This commit creates an ID for create-field-btn and initializes the
click handler on this button, instead of the form; the side effect of
that change is that we're now no longer double-adding this click
handler every time the page is opened.
This isn't a clean solution; ideally, we'd only call the function to
add the click handler once in the first place.
Fixes#10126.
Importing the Django test client is somewhat expensive, and we only
use it within one view function that's not used in production. So
there's a significant startup-time performance optimization in doing
an import inside the view code.
python-twitter was consuming a significant amount of import time.
However, this commit seems to not save any time at all, probably
because its recursive dependencies are imported elsewhere in Zulip.
This test refactor makes the subscription/stream settings changes use standard
APIs and thus be easier to follow (and more robust to subtle re-fetching bugs).
This is a follow-up to #9181.
Function `update_announce_stream_state` is used to update announce-stream
checkbox. If stream is private announce-stream checkbox gets disabled
by this function.
There are unncessary calls to `update_announce_stream_state` fuction.
i.e. it is called
- when user clicks on `copy-from-stream` link to toggle streams-list
- when stream-checkboxes value is changed to copy subs from stream
- when user-filter value is changed to search users
These events does not affect announce-stream value, therefore
there is no need to call this function to update it.
Currently, our edit-field-choice form in custom profile field settings
in admin UI, is rendered when settings modal is loaded not when admin
user clicks on edit-btn.
Admin user open edit-field-form of choice-type-field, do some changes
in choices, discard those changes and close edit-field-form.
When admin user again open this edit-field-form, those discarded
changes are displayed, instead of original choices data.
Fix this issue by re-rendering field choices when admin user clicks
on edit-field-btn.
Admin user must enter at least one choice for choice type fields
in create new custom field form. Admin can not delete all choice
options in form.
Reset delete-btn of choice inputs on choice reordering so that
admin can delete all choice except first choice input option.
Currently, admin user has to add order of custom-field-choice in
input box to create and edit choice-type custom field.
Remove this input boxes and add drag-drop list of custom-field-choices
using Sortable.js.
Fixes#10129
Renaming a user group to a name shared by other group wasn't a scenario
handled by the backend, and the server errored whenever this was
attempted.
Now a json_error is returned, letting the user know that a user group
with that name already exists.
In Chrome, the loading spinners on the Bots and Deactivated Users pages
were not visible due to the `filter` elements having duplicate IDs across
the different pages. (There are multiple `filter` elements with the ID
`uil-ring-shadow` on the page.)
To solve this, when generating a new loading SVG element, we append
the container element's ID to the filter's ID, thus preventing any
duplicates.
Fix#8620.
The use_first_unread_anchor parameter allows automatically setting the
anchor to the first message that hasn't been read in this narrow.
Therefore it isn't necessary to specify an anchor when this parameter is
enabled.
Note from Tim: Arguably, we should think about making
`use_first_unread_anchor` the default behavior when anchor is
unspecified, but that's for later consideration.
110 is what we enforce in Python code via our existing lint rules, and
120 is what we'd most realistically move the JS codebase to next.
Make supported IDEs and text editors keep a maximum line length of 110
characters for most code files.
We found out in #9953 that, appparently, loading the OpenAPI file was
taking abut a 5% of the Zulip server startup time.
Since in many cases (especially in development) having the file loaded
won't be necessary at all, we read it on the first time data from the
OpenAPI spec is needed.
Tweaked by tabbott to add a test.
Automatically detect if the OpenAPI spec file has been modified since
the last time it was loaded into memory, and if it has, automatically
reload it to have the latest version.
This feature is designed with development environments in mind. The main
benefit is being able to see the changes made to the OpenAPI document
without needing to restart the development server, which is tedious and
slows the documentation workflow down.
Marco Burstein
Eeshan Garg
Tim Abbott
Steve Howell
Yago González
Harshit Bansal
Yashashvi Dave
Shubham Dhama
Cynthia Lin
Shubham Padia
Rhea Parekh