I've already installed these packages on staging, and will install them on prod
when the commit hits master. So there is no manual prod deployment step here.
(imported from commit 1b77e771f938305dfbeb797c3ea2a7e3897e78a7)
And keep the fields updated, by copying on UserProfile creation and
updating the UserProfile object whenever we're updating the User
object, and add management commands to (1) initially ensure that they
match and (2) check that they still match (aka that the updating code
is working).
The copy_user_to_userprofile migration needs to be run after this is
deployed to prod.
(imported from commit 0a598d2e10b1a7a2f5c67dd5140ea4bb8e1ec0b8)
This has the nice side effect of not requiring us to trigger the
events manually in the success callbacks of our subscribe/unsubscribe
ajax calls.
(imported from commit e8d9970b708e9832d22be4803570071bacb46792)
We currently only use these events to change the autocomplete lists.
I figure that the presence list will be updated by presence events.
(imported from commit e9c1466659c4bfd463806656e0023984a4ea4177)
Now that we're distributing these examples, we shouldn't be promoting
the use of the "--site" option.
(imported from commit 01ded4a851dc799fa6c7e902e937c4331ed92bf8)
I can't reproduce the problem this works around anymore. If it comes back,
let's debug and figure out what's happening.
(imported from commit 26096405a93a530e449c9f1f60d8110b1bb0e96b)
We were incorrectly using User objects, rather than UserProfile
objects, for fetching Recipient objects for generated messages.
(imported from commit c3dfe52f4e0a68400e22ca49293b5bf2d6986402)
Our testing code had a number of places where it was using User
objects where it should have been using UserProfile objects --
e.g. using a User id as the type_id in a Recipient table. This commit
addresses this in the filter_by_subscriptions code paths.
(imported from commit e305bc8e2a8bdbfd04c93c59d56955e7971552af)
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)
The previous version of our code only worked with python-requests <
1.0 (as is the case on our servers), the new version will work with
any python-requests new enough to have a .json at all.
(imported from commit 77ffe3e0d890fe88776c313e0e3289aee1bb30ea)
A ticket is filed and this error is not fatal to the UI but rather
a warning to investigate, which we will now do
(imported from commit 3f67ec2b503e91b3921e33b89febd97790e389f1)
Before this commit, if you try to arrow around when the selected
message is outside the pointer threshold for recentering, you get a
big jump, even if you are arrowing towards the center of the viewport.
(imported from commit 5c15d5ccccdf027a8bfa8b79bf519fccbfa971d8)
Keegan McAllister
Tim Abbott
Jessica McKellar
Zev Benjamin
Waseem Daher
Leo Franchi