Otherwise these logs will end up all getting split up when we switch
to the new deployment model.
(imported from commit 0514c296470be7113cab6c2f48e8dd33f1b9353d)
This is a V1 of this feature. For now, the only way to expand is by narrowing
to the stream---future revisions may add a manual toggle if it is found to be
useful.
Additionally, showing per-subject unread counts will be coming in a future revision
as well.
(imported from commit fb5df0d27e928fa3b0f32b9ff2c1c508202cf7e5)
This commit will incorrectly list past-online users as active, a shortcoming that is
addressed in the next commit
(imported from commit b018767df686f88c0ca939c067c573e4d7cea357)
Boto usually handles this for us, but can't do autodetection like it
normally would because the file path we tell Boto isn't the original name
of the file.
(imported from commit 1ad4b04baf39be8887c86f7238438580651874ff)
Otherwise it applies to all password-type <input>s, which is not necessarily
what we want.
(imported from commit da2bb86961f4ff1dcc48e89e51abac6dbea79548)
We now have the bar color to indicate (for most users) whether the password is
valid, so revert to the default validation behavior and don't validate before
the first blur.
(imported from commit 5c2f6e05a8796033942a2af62f244b61459ff1bb)
And scroll there on any error (previously, we would scroll only if we end up
submitting the form).
(imported from commit 63597c4da78ac92cd5c2314d6d174d178b1caaf3)
It seems to have no effect and does not appear anywhere else in our repository
or in jquery.validate.min.js.
(imported from commit c4d2f730f3b680e15af17cefee34f6930e64ade0)
Otherwise, if you get an error those e-mails are still around the next
time you try to invite someone.
(imported from commit b521a74f4d6c0d67271f804221f519d1aa7551ff)
This avoids 10s of seconds of delay when you invite several people at
once through the web UI.
(imported from commit 75acdbdb04caf62bbb08affc7796330246d8a00e)
This fixes user-visible browser errors caused by trying to use the id
of messages in an empty message list.
One error could be triggered by trying to go to the end of your feed
with the End key during a reload.
Another could be triggered by trying to narrow to a stream or subject
using hotkeys while in an empty narrow.
(imported from commit a0e5456fd3b475aecac6eddd7104772baaf3aeb8)
This also changes the API for GET /json/subscriptions/property to
only retrieve the property for a particular stream instead of
returning all streams and their properties. We weren't using this
functionality anywhere and the change makes the API more consistent.
(imported from commit 2799aec2550fd0558e2282beb19734d60801bdb8)
I noticed that on chrome, calling narrow.deactivate() actually ended
up calling itself recursively due to the hashchange code not correctly
handling the fact that in Chrome if you set
window.location.hash = '#';
and then read out the value, you get '' back out.
(imported from commit 9b5047fbe0e2ac1846e5325d066c72306634c523)
What was happening is that if you un-narrowed immediately after
receiving a message (e.g. because you just sent it), the autoscroll
animation from the zfilt table would still be running after you return
to the home view, resulting in the viewport being scrolled to an
apparently random point in the home view (even though the pointer was
still in the right place).
This cancels the autoscroll animations whenever you do one of:
(1) hashchange (e.g. to go to the settings page)
(2) select a message (covers narrowing/unnarrowing as well as keyboard hotkeys)
(3) mousewheel scroll
since those are basically the cases where we set the viewport
scrolltop directly.
Arguably this should instead be something where we somehow detect
which scroll events are triggered by what and cancel for any scroll
event not from the animation or rererendering, but that seems hard.
(imported from commit f776021303404c87b36241c733b3d1bcb083163b)
The previous code for adding users to default streams wouldn't do so
if the user didn't have a PreregistrationUser row.
(imported from commit 25f1383f6771319542d07660b29d891368889212)
Now that our plugin is in the Jenkins marketplace thing,
we don't need to have the user laboriously download it
from us and upload it themselves.
(imported from commit 25e9926f7f2314db8f3ea6c00c40514b6fd546c3)
For our primary measures of user engagement, messages sent by bots can
confuse the picture (e.g. a realm could be dead, but not appear to be,
because they didn't bother uninstalling their github and jenkins
hooks). So it's best to leave those out of our main stats.
(imported from commit 4d0f0e6442093daab164d0ed016fff1d1aa906c7)