Added field invited_at on zephyr.PreregistrationUser, with a one-time
default of Jan 1, 1970 for existing objects.
Added M2M table for streams on zephyr.PreregistrationUser
Deleted unique constraint for ['email'] on zephyr.PreregistrationUser
(imported from commit 85247acb488201f8fc51dfaae354423c27eddcb0)
This allows us to handle the return_messages_immediately part of
get_updates requests without having to talk to the database.
(imported from commit ed0b7742d359efb21a0a4960f4fc25f4337e9ad4)
This commit has the effect of eliminating all of the non-UserActivity
database queries from the Tornado process -- at least in the uncached
case.
This is safe to do, if a bit fragile, since our Tornado code only
accesses these objects (as opposed to their IDs) in a few places that
are all fine with old data, and I don't expect us to add any new ones
soon:
* UserActivity logging, which I plan to move out of Tornado entirely
* Checking whether we're authenticated in our decorators (which could
be simplified -- the actual security check is just whether the
Django session object has a particular field)
* Checking the user realm for whether we should sync to the client
notices about their Zephyr mirror being up to date, which is quite
static and I think we can move out of this code path.
But implementation constraints around mapping the user_ids to
user_profile_ids mean that it makes sense to get the actual objects
for now.
This code is not what I want to do long-term. I expect we'll be able
to clean up the dual User/UserProfile nonsense once we integrate the
upcoming Django 1.5 release, with its support for pluggable User
models, and after that I change, I expect it'll be fairly easy to make
the Tornado code only work with the user ID, not the actual objects.
(imported from commit 82e25b62fd0e3af7c86040600c63a4deec7bec06)
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)
We suspect that these seem to be causing a regression where scrolling
in narrowed views gets really sluggish, but we haven't totally been
able to figure out why since it's challenging to reproduce locally.
(It currently manifests itself on staging but not prod.)
So for now we'll back them out. Here's the full set of things:
Revert "Cause update_floating_recipient_bar to get called less frequently."
This reverts commit a6c1518c4001a2dde44d7b512236795da3ccd351.
Revert "Remove double-scroll in un-narrowing code."
This reverts commit 3dde6c27ffa1e8afa1a084b1b2baee3bc0512962.
Revert "Reset our scroll position if we change our hash to "#"."
This reverts commit 925b44d770c96dafaabebc9e0114f9a3b8f53c4d.
Revert "Properly update floating subject bar when you are at top of page."
This reverts commit 6633cc8a81aedcbb31b30d7c1f27816f8808c700.
(imported from commit a273730581cef30c33bedf701659ee084434f8ad)
Note that on local dev servers, this will print out every half second, as
Tornado polls for file changes for autoreloading. In production it will only
print out when network events occur.
(imported from commit adfe88879e4e446b7dfa6ee69e0a9ad013e9c4d4)
This should remove a database query invoked from Tornado by our
decorators in the common case.
We use hashlib.sha1() on the key because memcached doesn't support
keys with whitespace in them.
(imported from commit 351ef4c76bc68e2d53f0e7ddca91dcf95e7bb2a6)
Previously it wouldn't work due to using the wrong port numbers.
This commit also has the side effect of fixing the fact that our
frontend tests would send real emails and log events to the real
message log.
(imported from commit f2cf400e6061c089627acba2759d588981ecf5bb)
This should save a database query when we later need to access fields
such as the user's realm name in format_updates_response.
(imported from commit ceef726db9e917cfb0b47061130d7299ee64890d)
This code is from a previous protocol where the users array was posted
as a comma-separate list, rather than encoded via json.
(imported from commit 3a2edfcbf250a7eef305b2e98018c1361cc2fffe)
This is for consistency with the rest of our code dealing with message
delivery, which always uses the user_profile_id.
(imported from commit 5bf10bb9b994b0a98d3a22bd0bd86e542ab8a2ee)
Putting update_floating_recipient_bar in the old location caused it to
be called on every single keypress, which is unnecessarily
expensive. Instead, just call it once when we think we might actually
need it: after initiating a narrow.
(imported from commit a6c1518c4001a2dde44d7b512236795da3ccd351)
Watching new users, I've seen them not notice the pointer and
mix. Give them a little more hinting about what message is selected.
(imported from commit c98e22dcef881ed7400071ec438a6e91d6cd3d9e)
select_message_by_id with then_scroll: true already recenter_views
on the selected message; no need to also call scroll_to_selected.
(imported from commit 3dde6c27ffa1e8afa1a084b1b2baee3bc0512962)
Changing the hash to "#" causes Chrome to jump to the top of the page
on Mac OS X. This commit doesn't actually fix any bug, but it
is necessary for my *next* commit, where otherwise you'd have to
ensure that the scroll code came *after* the hashchange code.
(imported from commit 925b44d770c96dafaabebc9e0114f9a3b8f53c4d)
There's this very edge-case issue which is: if you go to the top of
the page and narrow to something other than the top message, the
floating subject bar does not update.
Why? Well, the way that the narrowing code works is that it sets up
narrowing and then calls
select_message_by_id(target_id, {then_scroll: true});
so that our selected message is in the view.
This in turn calls select_message, which calls recenter_view as
appropriate. This usually causes a scroll action, which in turn causes
the floating recipient bar to be updated.
But when we're at the top of the page, recenter_view doesn't need
to scroll at all! So the bar remains un-updated. Here we explicitly
update it to guard against that case.
This fixes Trac #651.
(imported from commit 6633cc8a81aedcbb31b30d7c1f27816f8808c700)
I don't view this as a complete solution to
Trac #466 - Make the fact that you are narrowed more apparent,
but it's a start.
(I think a real solution would have to give you something that
helps you make the determination of "Is this view narrowed?"
when you come back to your computer, and this animation does not
help you do that.)
(imported from commit eb3646f3f3a4e25a43266e9146308633fd997eb2)
This commit just moves around some lines so that the code that
hides the main view and shows the filtered view, or vice versa,
are together so that it's easier to reason about the sequence
of things that's happening.
(imported from commit 7e99f45293c0e1a4cdfa1a08f41f8c770c370d6c)
This used to be a button that let us un-narrow, I guess.
A git grep for it after this commit turns up no actual
references to it.
(imported from commit 05acb4bb40da1b032f548c511fbae5b2b20874a8)
Luke Faraone
Waseem Daher
Jessica McKellar
Keegan McAllister
Tim Abbott
Zev Benjamin
Jeff Arnold