I think all that one needs to do to deploy this commit is on developer
laptops, run `generate-fixtures --force`.
(imported from commit 34916341435fef0875b5a2c7f53c2f5606cd16cd)
We were incorrectly using User objects, rather than UserProfile
objects, for fetching Recipient objects for generated messages.
(imported from commit c3dfe52f4e0a68400e22ca49293b5bf2d6986402)
This way we're not directly manipulating user.password() in random
management commands.
(imported from commit e6e32ae422015ab55184d5d8111148793a8aca36)
The previous situation was bad for two reasons:
(1) It had a lot of copies of the code, some of them missing pieces:
UserProfile.objects.get(user__email__iexact=foo)
This was in particular going to be inconvenient since we are dropping
the __user part of that.
(2) It didn't take advantage of our memcached caching.
(imported from commit 2325795f288a7cf306cdae191f5d3080aac0651a)
Only a few of them took a User as an argument anyway.
This is preparatory work for merging the User and UserProfile models.
(imported from commit 65b2bd2453597531bcf135ccf24d2a4615cd0d2a)
This saves 2 database queries per user in the huddle when sending the
first message to a particular huddle.
(imported from commit f71aa32df846fb4b82651a93ff9608087ffcaa5a)
The idea here is: part of the onboarding tutorial is going to
be you talking to the tutorial bot and it talking to you, from
our Javascript.
The reason it's driven by Javascript is that then in principle we can
do nice stuff like making popovers appear in places to point things
out to you, whereas if we were to do it strictly server-side, doing so
would be a lot harder.
The downside to doing it in Javascript is that you don't get any of
the Markdown rendering, since that happens on the server. So instead
we add this call where you give it a message, and it responds by
having the tutorial bot send you that message.
I don't think there are any security concerns here because
(1) The bot only messages you -- so you can't use it to make someone
else think that the system is telling them to do something
(2) If there were an issue associated with having the server parse
arbitrary Markdown, you could just trigger the issue by sending
a message yourself.
(imported from commit b34f594dab6be6bcb81899278ae1cbe447404468)
The production database will need to have this user created before
this commit is pushed
(imported from commit cc8356d8afa0f0747486b7b4c82337c60499d3fd)
We need this so that we can safely expunge old events without interfering with
the running server. See #414.
(imported from commit 4739e59e36ea69f877c158c13ee752bf6a2dacfe)
Otherwise one gets:
AttributeError: 'module' object has no attribute 'time'
when trying to use the time module from inside zephyr.lib.
(imported from commit 645368672a3eff68320278dd480edeed56721fcc)
So, I got annoyed that our test suite was taking forever to run:
real 2m13.443s
user 1m32.630s
sys 0m3.748s
Some quick profiling determined that the test suite is spending all of
its time loading the fixtures files (zephyr/fixtures/messages.json)
that it loads for each test case (3s to load that for each test case).
To improve this situation, I cut out from the test database used by
the test suite most of the users, subscriptions, etc. that aren't
being used directly by the test cases. The impact is a quite
significant speedup:
real 0m15.176s
user 0m9.161s
sys 0m0.508s
We're still spending over a quarter of a second per test, which isn't
great -- but this is at least no longer unbearable.
This commit doesn't make any changes to the populate_db output if you
don't pass the new --test-suite option.
(imported from commit 2334ba5399b33edab3d29ff269fde4ea77ccd48e)
This is needed to avoid exceptions trying to do internal_send_message
in any test against a simple populate_db database.
(imported from commit 36927f57cbbb7e30ae249b5f1a0549fb352827f5)
Importing zephyr.views here has the unfortunate side effect of
creating Client ids 1 and 2 automatically (via decorators.py
instantiating the two client objects it makes), before we go ahead and
delete all objects in the database as part of the populate_db startup.
(imported from commit da03cb7606334d5926e42f422ab94d1c884937b9)
Previously, the StreamColor restore code didn't properly account for
the fact that most user subscriptions were in pending_subs and thus
not yet in the database.
(imported from commit 2e28c5a68aa045494b9336d7114c23f5c3706c28)
By processing UserMessage objects in batches as we go, this avoids
consuming a large amount of memory that is linear in the size of the
messages log.
(imported from commit 0c42d97f0863da9c079836c60bebcbaeec59f849)
We previously were only using it at the first loop through all
messages, which meant code accessing the message type copied from one
place to another would break (potentially subtly), because things
would work if and only if the very last message happened to have the
same type as what is expected in the relevant piece of code.
(imported from commit ad9ce5efdb200e0c0d5c3ffa6db33113fdad8c5a)
This cuts a 30s operation down to about 2s on my machine.
And also move the code to run before we print the "done" message and
have logging for how long it is taking.
(imported from commit 2f20f8ca3fee714735a50fe6c6cfd630df452768)
When we changed our stream name model to treat stream names as
case-insensitive, we didn't update populate_db to do the same.
This commit makes that update, which is to use the lower-cased stream
name for dictionary lookups and deduplication, but the original-case
stream name for actually creating streams.
(imported from commit fc32ec75a5ae286bce7ec86c6e6fb6893888cbd0)
authenticated_api_view and authenticated_json_view call
update_user_activity with a client generated using
@has_request_variables with a default of e.g. get_client("website").
Because that get_client call only happens once on importing the
module, if those client objects didn't exist previously in the
fixtures, then the first test will generate objects with ids 2 and 3,
and then the second test will dump the database, restore from the
fixtures, and then eventually generate client objects with ids 4 and
5. But since the default values were only computed at module load,
we'll still end calling add_user_activity with client objects with ids
2 and 3, which don't exist in the newly restored database.
Fix this madness by just making sure those two client objects exist in
the database.
(imported from commit d940e129d077a560d9a0f96ec3daa2e16ce21c8b)
Run this script on an existing realm to create or change default
streams, which new users will get upon account creation.
(imported from commit 8938dcbd3520d97d25b4c6ca783d35c9aef52df0)
Zev Benjamin
Leo Franchi
Tim Abbott
Waseem Daher
Keegan McAllister
Jessica McKellar
Jeff Arnold