We have observed additional exceptions being thrown from zulip_finish and we
need to make sure that the handler is disconnected from the queue, or else the
event queue will keep throwing exceptions due to the handler being closed.
(imported from commit 59273aa14495216430b9eb1525b2cce230d8913d)
Before this change, you could open the Administration page
for a 2nd time, and there would be two copies of each stream.
The simple fix is to remove any existing rows before populating
the table.
(imported from commit 957306d9c6418e59b5b288dad08864547ca63e53)
This is the "Tried to call a Dict method with an undefined key" error
because it tried to look up stream information for `undefined`.
(imported from commit 0187f185f3e424a0c9ea940d9b32f07376ac8952)
This prevents us from failing if the first or last name is unset.
We fall back to None, which will allow the user to set their name even
if real names are restricted, which is probably better than forcing them
to have no name.
Closes trac #2118.
(imported from commit 1ff8a55022f3a3baf67575b593a679e21c0f3194)
And in the meanwhile, comment what's going on so that we don't break
this in refactoring again later.
(imported from commit a3119cd1eab3d54cb1883f2c8cad0d147cb04ba7)
Currently all of our realms we intend to create are created manually,
and regardless do_create_realm is the correct way to create a realm.
(imported from commit 42280aff461aa17ffee22ab1c7b7f43757648eec)
This way command-line scripts that use our `optparse` populator can
still specify a custom client without munging their `parser` object.
(imported from commit df8d28a46a4d4574523b106030dbfed2d9ac931e)
We previously sent our client type to the server as a GET/POST parameter
of "client=<something>", most commonly "client=API: Python".
We switch here to providing the same information as a User-agent header
sent on each request, which is more standards-compliant.
Also added is some data about the platform the user is using. If your
client string was set to "MyLittleZulip/1.0", the resultant string could
look something like this:
MyLittleZulip/1.0 (Ubuntu; 12.04)
(imported from commit 39fd187a8f9d4b3c9b63fc623e0836e57a4099ca)
There are now 2 cases for narrowing:
1. We narrowed, but only backwards in time (ie no unread were
read). In this case, try to go back to exactly where we were before
narrowing. This behavior is unchanged.
2. We read some unread messages in a narrow. Instead of going back to
where we were before the narrow, go to our first unread message (or
the bottom of the feed, if there are no unread messages). This is new.
This means that after catching up through the sidebar, on returning
home you'll be at the bottom of your feed.
Searching for the first unread message in a message list with 40,000
messages only takes 17ms according to:
function timeit() {
var t0 = new Date().getTime();
_.find(current_msg_list.all(), unread.message_unread);
var t1 = new Date().getTime();
console.log('Find first unread: ' + (t1 - t0) + ' ms');
}
(imported from commit 87c467578a2cced0aa976d8ae2924371b85d2445)
This reverts commit f81f4b2739cbf8e3d3c2db5e467cf55b65f0c2bd.
Conflicts:
static/styles/zulip.css
(imported from commit 6e62619a5f16f120134b222b331a066a57b7cfc6)
This changes the algorithm slightly for the 2-block case, because
I simplified the logic to just divvy up the space naively based
on the relative size of the blocks.
(imported from commit 9498edd916f65e07fb64d138276691d0d5cc0e55)
This is a functional change. Before this change, the stream
list and user list were allowed to take equal space in the left
sidebar; now, we take the size of each list in deciding which
proportion each block gets.
(imported from commit febedcb0518353825e18a6ebe60d1883b98bc78d)