This is probably a lot more annoying to use, in that e.g. there are
separate log files for the two directions of the mirror, but we
haven't used these logs for much, so whatever.
(imported from commit d3bc407d90099214d242526c01cd3d3cd9d9d9bd)
Variables like stream, subject, and message were getting cleared from the DOM
when the compose box was closed. The "Create and send" button was trying to
access these variables to create a new stream, but they were gone. Now they
are cleared when a new compose is started.
Fixes trac ticket #568.
(imported from commit 39ccaaeacb3f92f4b1d771be1b34ff660e0d5883)
We now encase the request info in a preformatted block, which ensures we
won't accidentally trigger any formatting while being reasonably
space-efficient.
(imported from commit 7c69a6ff2b2abd9474aae08b5ba608bcb40cec56)
This should really be handled on a per-method basis, but in general we
don't want "password" or "key" to be sent to us for security reasons.
Addresses trac #569.
(imported from commit 1c246fce00f3740977c595641341ee36eb5ed831)
We were submitting a 'last' value of -1 to the server at startup,
which is invalid but normally ended up being OK because the user
usually had no messages whatsoever or had last be updated via
get_old_messages before the get_updates call went through.
(imported from commit df55ac1cdac443721c06ebed94a1c4b3ec7af2d1)
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)
This was not totally effective, and with the previous commit it is no longer
needed.
This reverts commit e86c0b653669cf86b0d8956c2c85eb7610fc342f.
(imported from commit 0de5bfec87147b1336f6f79c33d4e32493e1e508)
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)
This was causing issues with our ability to unsubscribe from
streams with " in their names.
The solution here is a bit hacky, since it depends on the JavaScript
being fairly aware of the layout of the DOM, which is not great.
But it works.
This fixes Trac #328.
(imported from commit a1b6c8e1f3a9daacdc48920a195717aa89b3a9a9)
This fixes Trac #522, which previously prevented you from
subscribing to a stream named
'"]'); alert('hi');
This does not fix#328, which is that you can't unsubscribe
from 'Waseem', among other things.
(imported from commit 869063cafa9e7e988aea993d072ca1ad880bcee1)
Unfortunately, this doesn't actually give us much performance gain
either; it's not really the calls to 'find' that are taking any time.
But I do find this a little cleaner as well.
Simply initializing 100 colorpickers with our options takes about 700ms.
Initializing ~100 colorpickers with the total default set of options
shaves that down to about 300-400ms (though obviously doesn't quite
achieve what we want).
(imported from commit 7084b35fb6e77600edfcdcfcc2761a11e6f38c03)
Rather than calling the template generating code once per
subscription, let's just do it in a batch when possible.
With about 100 subscriptions, the "fetch" call takes about 800ms to
render (while testing locally) both before and after this change,
which is somewhat disappointing.
But this *is* cleaner!
(imported from commit 9ba8819524da86c00a2508349be0ea0ddd48606b)
This is useful when testing the sigup workflow, as this script enables you
to run through a MIT signup without manually creating a new inactive user
in the database.
(imported from commit c22649cc7c561c2fbe8682d1b17d7e5aba9ac04e)