Now, we further clarify in the create-stream.md macro that even
if users follow our default stream name recommendation for a
given integration, said stream must still be explicitly created.
jQuery's behavior in methods that, because of their nature, don't need to
return anything is to return the element itself in the jQuery object form.
Now the zjquery element is returned when one of these methods is called.
There are some cases when the jQuery dollar
function is called with an element as argument.
If such element has already been created using
zjquery, we should simply return it.
Since util.extract_pm_recipients() won't return a recipient if it's only
composed by whitespaces, considering such recipient in the matcher is
unnecessary.
Similar code appeared at two places (the code is meant to remove the
leading @-mention before passing the remainder of the message to the
bot handler)—both 'zerver/worker/queue_processors.py' and
'api/bots_api/bot_lib.py'.
Remove function from the queue_processors.py file and let the entire message
be processed (includes removing of @-mention) at bot_lib.py.
On some developer machines, casper was having trouble clicking on
a hidden button. Added a step to make sure the button was visible
before being clicked on.
Also removed an unnecessary log line.
This ensures that everyone runs provision to pick up the change from
8ff2e5a22 requirements: Upgrade moto to latest version.
Otherwise, backend tests fail (compounded by the error being made
quite mysterious by the parallelism framework, when running with
parallelism as we do by default) if running on code after that
change while last having provisioned before that change.
This commit fixes the order in which we run the test suites in Travis
CI. Most of the PRs include changes only to backend/frontend and it is
fairly rare for them to break production test suite. Since travis runs
atmost four jobs at a time, most of the time developers need to wait for
the production suite to get completed so that the backend test suite can
start which has a fairly large chances of being broken. Now, we run the
production test suite in last.
Guardian adds functionality on top of Django auth system to set
per object permissions. Its problem is that it is has poor performance.
So we decided to remove it in release 1.4.0, but we still kept the
option to revert back to an older version which used Guardian.
See commit 49799440a4 for more details.
This commit is the final piece in the string of commits which move
us towards completely removing guardian from our codebase. The way
we do it as follows:
If you are upgrading from a version <= 1.3.10, you first need to
upgrade to 1.4.x (we recommend 1.4.2). The reason is that we
deprecated Guardian in this version. Once you have upgraded to
1.4.x we can be sure that your Zulip installation doesn't depend
on Guardian and all the data has been successfully migrated away from
Guardian. The second step is to upgrade to latest release which will
not include any reference to Guardian in the codebase. After this
commit migrating directly to the latest release will not work because
in that case Guardian data will not migrate.
The backward incompatible change that this introduces is that
we have squashed all the migrations till version 1.4.0. This was
necessary to remove Guardian because it was needed by the reverse
migration. These migrations were from 0001 to 0028.
Fixes#5420