When you return to Home, we normally restore your last
position when in Home, which might have been before the
first unread message. This is cumbersome for sidebar readers,
so now we keep track of messages that you visit while on a
tour away from Home, and when you return Home, we skip forward
any messages that were in the tour, landing on the last visited
message. This all happens before rendering.
(imported from commit 9124a231d94f153e283e5ea95e40c50a58406275)
The goal here is to make it so that we can do other stuff with
the range of messages between two subsequent selections, besides
marking them as read.
(imported from commit f6eb07844fb2ccda195c9d4dfcdf1c15f3f40aff)
When hover over a typeahead menu item, the semantics have always been
to make it active, and now we also respect the naturalSearch option
there, which will set the text of the search box to the suggestion
immediately upon hover.
(imported from commit 02318d3d830e7e28d638efee0ef27023a73f52f7)
See https://github.com/twitter/bootstrap/issues/7392. I seem to
have fixed it with just the CSS part of their suggested patch.
To repro the bug prior to this fix, enter search, hover over a
typeahead, and then hit the up arrow key. You'll see two items
appear to be selected.
(imported from commit 383d60a606d7c19344a326208312a1555d060877)
This commit broke unread dots, since they're in the .messagebox
but absolutely positioned outside of it (so they got clipped.)
This reverts commit e0071851d2dc7d99c9acd93a1fc6fa1ce0c3b70e.
(imported from commit b3181b3a02cef905cc8f400f8c1cc3c92b5f0e15)
The total duration of this animation is the exact same, but
it starts immediately - let's see if this feels any better.
(imported from commit de86c259a25adb64514613579476480bdac29cb2)
There was some misguided code that eliminated the suggestion when
the user typed out the full topic, and since then there is more
generalized protection against duplicate suggestions.
(imported from commit 857e74458d10995170d312b77d99d839706ae680)
I'd encourage you all to review this diff thoroughly, since I am not
very familiar with this code. However, it seems to me that, prior to
this commit, if respond_to_cursor is true and page_params.staging is
true, compose.start gets called twice! (once by `respond_to_message`
and once by the "if (page_params.staging)" under the else, after it
returns.)
I eliminate the second call by sticking it inside the first else; now,
as far as I can tell, we call compose.start once and only once.
(imported from commit 319f51392541def358a138c104dd21722b4f8ba8)
The value it is passed is usually https://staging.humbughq.com, not
just staging.humbughq.com.
(imported from commit c3cd8fc5baa767377f506570aa8e7d2e1ed399ec)
Just before this is pushed to prod, we need to rename the Humbug feedback
bot in the database using:
./manage.py change_user_email feedback@humbughq.comfeedback@zulip.com
/etc/init.d/memcached restart
and we also need to update and restart feedback-bot in its deployed
location.
No action is required on pushing this to staging, but in between when
this is pushed to staging and when it is pushed to prod (and that
transition performed), feedback will not work on staging.
(imported from commit 73fc36f680b978f3aebae5df1822918ae4d4e952)
Just before this is pushed to prod, we need to rename the Humbug
notification bot in the database using:
./manage.py change_user_email humbug+notifications@humbughq.comnotification-bot@zulip.com
/etc/init.d/memcached restart
No action is required on pushing this to staging, but in between when
this is pushed to staging and when it is pushed to prod (and that
transition performed), notifying users that they were subscribed to a
new stream will not work on staging.
(imported from commit a0555527dec7b210022b09d9b1d13a7c910a8f9f)
Just before this is pushed to prod, we need to rename the Humbug new
user bot in the database using:
./manage.py change_user_email humbug+signups@humbughq.comnew-user-bot@zulip.com
/etc/init.d/memcached restart
No action is required on pushing this to staging, but in between when
this is pushed to staging and when it is pushed to prod (and that
transition performed), signup reporting to humbug will not work on
staging.
(imported from commit af2cd007b41ea885491f383442f211e8609fe5f9)
Just before this is pushed to prod, we need to rename the Humbug error
bot in the database using:
./manage.py change_user_email humbug+errors@humbughq.comerror-bot@zulip.com
/etc/init.d/memcached restart
No action is required on pushing this to staging, but in between when
this is pushed to staging and when it is pushed to prod (and that
transition performed), error reporting to humbug will not work on
staging.
(imported from commit 93044bb01797c981067f359676826d4a5791e235)
When we push this to staging, we'll need to rename the bot in the
database and also pull on git.zulip.net.
(imported from commit 22b2397b197c8820f0e55daecd8f98d829e195bd)
The rename of humbughq.com to zulip.com had the side effect of making
users often not subscribed to stream Verona, which didn't work well
with our test suite.
(imported from commit 28ebd5b444a026e753935ae99b3baa203bb0f222)
Before we'd autocomplete d to [stream:design, stream:devel].
Now we also autocomplete stream:d to [stream:design, stream:devel].
(imported from commit d7ecbd032a3414828bf649698d741f0d6a6e3af2)
This helps mitigate the damage caused by hilarious vertical
names like "Puerco (((((())))))" with the vertical parentheses.
(imported from commit e0071851d2dc7d99c9acd93a1fc6fa1ce0c3b70e)
I often click "reply" and clear out the text to reply to these, and
it's sort of a pain to have to change the address.
(imported from commit ed8aae858bbd1821623cf640956ffccbacfaa1af)
Steve Howell
Waseem Daher
Zev Benjamin
Waseem Daher
Tim Abbott