Previously, we used Integration.name as the recommended stream
in our macros. Now, we have a dedicated attribute set in the
Integration class (that WebhookIntegration and GithubIntegration
inherit from) for the recommended stream name in cases where
the stream name is different than the name of the integration
itself.
Instead of using the name of the integration as a recommended
stream name in its documentation, the Integration object now
has a dedicated attribute stream_name to explicitly specify a
recommended stream name for when it is different than the name
of the integration itself.
Now REs have moved to template module. This commit adds a condition
to use trans_real module if the Django version is less than 1.11 else
use template module.
In Django 1.11, args argument of run_subsuite function is a tuple of
length 4. The new argument is the test runner class which we do not
need because we run tests using our own version of the test runner.
This makes our `zproject.jinja2.backend.Template` compatible with
Jinja2. After this change we don't need to override __init__ function
in Template class.
The only reason we now need to create our own Template class is that
we need to send template_rendered signals.
We need our own Jinja2 class because we need to maintain backward
compatibility with Django 1.10 and we need inject `debug` parameter.
This index is basically free, since it only consumes space for
messages that mention the user, but results in a massive performance
improvement when querying messages that mention a user.
This index is essentially free, since it only consumes resources for
starred messages, and massively improves the performance of the
"starred messages" narrow.
Wasn't being used outside the file, the URL is specific to
ConfirmationManager, and it makes
EmailChangeConfirmationManager.get_activation_url more obviously parallel
to ConfirmationManager.get_activation_url.
I think it makes sense to wrest the email sending from confirmation, now
that we have a clean email-sending interface in send_email. A few other
reasons:
* send_confirmation is get_link_for_object followed by send_email, but those
two functions have no arguments in common.
* Sending email through confirmation obfuscates the context dict, and is a
relatively complicated piece of the codebase anyone trying to deal with
the email system has to understand.
* The three emails previously being sent through confirmation don't have
that much in common, other than that they happen to have a confirmation
link in them.
The .split('/')[-1] in registration.py is a hack, but a hack used several
places in the codebase, so maybe one day get_link_for_object will also
return the confirmation_key.
We're about to make a change where we no longer deal with confirmation
objects in these email pathways.
The "if settings.DEVELOPMENT and realm_creation" is a bit of a hack, but no
worse a hack as was there before, I think. I think it's also less confusing
if the method signature matches what happens in production.
This fixes the faulty spacing around the various icons in
stream accessibility option under the create new stream modal. This
regression was introduced in 7e71bf.
We now make it so that $('foo').addClass(whatever) and similar
functions properly return the wrapper object for chaining
purposes. We may eventually want to change the wrapper object
to automatically dispatch to the first child object, but this
should work for now.
Eeshan Garg
Umair Khan
Steve Howell
Akhil
Rishi Gupta
Pweaver (Paul Weaver)
Mehanig
Robert Hönig
Aditya Bansal
Tejas Kasetty
Aditya Ramesh
Tim Abbott
vaibhav
Brock Whittaker
Joshua Pan