This tab shows how long each user has been on during the last 24
hours, using data from UserActivityInterval. Much of the code
is borrowed from analyze_user_activity.py, but in this version
we set the time interval to be the last 24 hours and sort by
realm and email. I also ensure that it only executes one
query to get all the data (and there's test coverage for that).
(imported from commit 7a2b80f52679054b03c5f5f42b2cda07d5599432)
Waseem is ok with removing the client-specific tabs on the
main /activity page. This reduces the number of queries from
25 to 1. We might eventually restore some of that logic, but
we will do it more efficiently. A lot of the data for
non-website clients is kind of unreliable, anyway.
The page looks kind of funny with only one tab, but that
will be fixed in the next commit.
(imported from commit 54f08f89d5242ad3e045d8ca0d97b86617c15380)
When we don't already have old messages in cache, we need to
fetch data from the database and create dictionaries for the
cache. This commit makes that process work in 50ms, instead
of 130ms, for the data set in test_bulk_message_fetching(),
which is 602 records. Before this commit we had about 132
microseconds of unnecessary churn per message, because we
were fetching DB fields we didn't need and incurring the cost
of the Django ORM. Now we use values() to get only the columns
we need, and we take advantage of previous commits that make
our code less OO and more function-driven, so we can pass the
values directly to build_message_dict() without having to create
objects.
A couple caveats on this commit:
1) I haven't been able to get good measurements on the overall
effect on get_old_messages_backend(). If you kill the cache to
force DB queries, you introduce noise related to sessions and
user profiles.
2) Look at the long comment in this commit related to
re-rendering messages in this codepath. The problem precedes
this commit.
(imported from commit dcb64aa9416f0e9583355ddd6dc3adfa746b9fc7)
Only call a function on the message object in the unfortunate
situation that we are rendering new content in to_dict_uncached().
Long term, it would be nice if this function didn't have side
effects, and we had a better strategy for upgrading rendered
content when bugdown versions change.
(imported from commit 2a323f52af37a6d651c171cb8234fbfa3d25d561)
This function doesn't require the whole UserProfile object to
create the avatar url, and we call it from Message.to_dict_uncached().
(imported from commit e814caab101c4fedd1ba66df041a3408014e4085)
For a bunch of self-dot references, move them to the top. (This
is kind of funny out of context, but it sets us up for future
refactorings.)
(imported from commit 4ebc1c44a633d86772df1828c51180707769c3dc)
If this line of code were ever called, it would crash anyway,
because it would be an unknown type, and Recipient.type_name()
would raise a KeyError.
(imported from commit db38c5f71fb2f0b044a832eb88e53fceb0d8a9cf)
This is a variation of get_display_recipient that takes
values instead of an object, so that it is decoupled from
the Django object system.
(imported from commit 25bed43ecd62f1fe0176d517b7003e7f4c78bc37)
If it's ok for the tests to use memcached, it should be ok
for them to use the in-process cache too.
(imported from commit be43879c3c48f3780317fd5b4139b44d4a1f0ed3)
This is a harmless extraction designed to allow subclasses override
the behavior of how rendered content gets saved.
(imported from commit 9df4ed9f86c857897fcb5f2b6781bfc5a0813766)
The realm should always be the realm of the stream, and we should
always pass in a stream rather than sometimes passing in a stream name
and other times passing in a stream.
(imported from commit a098d6ed3db218a37c1b6b7c956e847c316c2d13)
It's a bit of a contrived use case, but you could make a topic
called "12345" and then mute it from the sidebar, and it would
crash inside Dict. We now call attr(), not data(), to avoid
string-to-integer conversions.
(imported from commit 89666f40d624df154d41077546e1c13a23ee7e67)
Before this change, you could narrow to an old topic, and it would
not show up in the sidebar unless it had unread messages.
(imported from commit f177a7378dac064e46a6417357cc86ada4475936)
The old code was looping through recent_subjects to find the
original subject name, but we already have logic in get_subject_filter_li()
to be case-insensitive. I tried this with various casings of topics,
narrowing to topics, as well as narrowing to a stream (so no active topic)
and narrowing to an old topic.
(imported from commit 1decde13477cb742fd4bc82798f1afb282182bdf)
Create our own objects for handlebars, so that we can add transient
flags like is_zero without worrying about side effects to other
code.
(imported from commit b351a369cb3f36233e108e270c7abdd4ab8c5860)
When we call rerender() on MessageList, it is usually because
something big has happened, so it's reasonable that the pointer
may now be invalid. As an example, the old pointed-to message
may been removed from the home view. We have always just
moved the pointer under the hood, but now we do it in a way
that doesn't generate spurious blueslip errors.
(imported from commit d399a101f36b744a423ea7da80dda8352440c6c9)
There is a scenario where we call process_read_message()
for a message that we haven't recorded as unread before.
I'm not sure how it happens, but I put back code to
guard against crashing. The regression happened in
5752458c821.
(imported from commit 5ce15d2e236b738b445ed88f1733aa0612be0ff3)
This has been deployed, so the current code is now properly
minified, and we don't need the force_minify flag any more.
(The flag is needed when you remove a JS file from JS_SPECS.)
(imported from commit 8b3c7ffdbc875011d59c2560034750f0077db616)
This fixes a blueslip error where we were trying to add the same
message into a MessageList twice. Muting complicates our duplicate
detection, because empty() can return true even when we already
are storing messages that just aren't shown (because of muting).
The name empty() should probably be fixed in light of muting,
but filtering with self.get() is not really a problem here.
(imported from commit 83b0890471c9a0aa21996f3d0d3be4a238f23e65)
We have been persisting muting preferences on the back end for
a while, but we haven't been adding them to page_params for the
client to have at reload/startup time.
(imported from commit d9ca68aa0e4d22bfb0e6ce67fc0bc63981175c8b)