Prior to this commit, successfully creating a stream (or unsubscribing
from a stream) didn't clear earlier error messages.
Here's how you could reproduce it:
* Try to subscribe to ""
(You get an error)
* Now unsubscribe from something, or subscribe
to a new stream
(The error message does not go away)
(imported from commit c3c6fa6081df00378182ff0c3499e9d907577c04)
Prior to this commit, we also cleared out all of your checkboxes,
which is frustrating if you wanted to invite another person to the
exact same set of streams.
(imported from commit 389f27ec35dc9bf8c9058c5ffa867929ac90f674)
Waiting for text "Waseemio" to appear isn't reliable, because the "create
stream" modal already contains that text. Instead, do a more specific check
for a .subscription_name element.
(imported from commit 54689aeb9d243c3fb62d1765b2b4fb93d3bb40db)
Note that the tsvector cache column should be fully populated before
commit is deployed. Otherwise, full text search will be broken until
it's populated.
(imported from commit 23c36fb7d146c289148e8243c3d6a9a6494cfc62)
This needs to be done in three South migrations to not block users
from sending messages for a long time. Adding the column requires a
write lock on the zephyr_message table and populating the new column
takes a long time. Thus, we can't do them both in the same
transaction (which South forces on migrations). Additionally,
creating the index takes a lot of computation and needs to lock the
table when not done CONCURRENTLY, which can't be done inside of a
transaction.
To do this manual change, you need to run:
python manage.py migrate zephyr 0007
ssh postgres.humbughq.com 'echo "CREATE INDEX CONCURRENTLY zephyr_message_search_tsvector ON zephyr_message USING gin(search_tsvector);" | psql'
python manage.py migrate zephyr 0008
on staging. No action is required on prod since the database is
shared.
Note that this migration must be done completely before we switch to
using the tsvector cache column.
(imported from commit b6a27013a60c1fd196eabb095d2d11d20bba5aac)
Because a stream can never stop being invite-only, we don't
actually need any Javascript to manipulate this besides what's
in the Handlebars template.
(imported from commit 30dc3b0baf623d88d03a643f18cd411dbe3eacfb)
If the database is down and the Handler crashes, we get an email with an
obnoxiously long subject line and without proper sanitization performed.
By wrapping internal_send_message in a try-except, we eliminate the most
common (read: to date, only) cause of crashes in our Handlers.
(imported from commit fd59e931ad0a4fff574d3cafa47348eacacb858f)
We also remove META here since it rarely contains anything useful, and
often contains sensitive environment vars.
(imported from commit 2909613f9f52684bef9175600961801104644c75)
This allows us to remove fetch_colors() entirely, and should speed up page
load a bit.
We also JSONEncoderForHTML instead of dumps so that the result is safe
to embed.
(imported from commit 013630911960e2ac1d0bae6f5df31ad342750594)
This will give us flexibility in the future to add new properties to the
list.
In order to support that, we now do a list comprehension rather than just
returning the gather_subscriptions list in get_stream_colors.
(imported from commit a3c0f749a3320f647440f800105942434da08111)
Previously we checked if property was false after doing .strip(). Since
you can't call string methods on a NoneType, we were 500ing.
The code now does a normal dictionary get via [] and catches the
KeyError.
(imported from commit da7f28febf0865f44e92bcac1791f817c3d370f3)
Returning json_error inside an inner function call will result in the error
getting lost.
(imported from commit fd7754b15f7b62fd6e4197fd72ae03d6996a93da)
Previously we made calls to the JSON api, which means that the API key
was being ignored.
(imported from commit 46d8d0e5ac7926e824f300fd846ec42bc939e2c0)
Autogenerated schema migration:
+ Added field in_home_view on zephyr.Subscription
To do this manual change, you need to run:
python manage.py migrate zephyr 0005
on staging. No action is required on prod since there is a shared database.
(imported from commit d554f17b25631482ec2d5605a42ac0b9d6df421e)
Previously we only got the user ID for /json requests, not /api
requests, and also only got the user ID, not the email address.
(imported from commit c3625f9c1a48430e35183be6c90a7855f3714948)
Introduced in d19991c7. //-style comments aren't supported in CSS.
This was causing update-prod-static to fail with a stack overflow.
(imported from commit 4cb11a7025e8fef32c852d691fccf18a5ad3b955)
This was removed in 63788aa3. It was the only non-symlink in
zephyr/static-access-control/.
(imported from commit c9ee043b07c5fd4050aeaafa40394a6b69915bfb)
This test case was supposed to be making requests as 2 different
users, but was not logging in as each of them and thus used the wrong
credentials.
(imported from commit 0dfdc86fcb385d3d2a721181b2f8075bc39ad723)
This came up when I tried to subscribe myself to an existing stream
name but with leading whitespace added; the get_subscribers request
failed with a 400.
(imported from commit 03fe370d1e80fd7e8c282f260e63b7e5ada05960)
Before, it let you subscribe only yourself or one other person to
possibly many streams.
This is used by the subscriptions page to specify the subscribers when
you create a stream.
(imported from commit c1055e98b0bb27799ac9e6dad80b9c9fd87deca2)
In preparation for re-using the /json/subscriptions/exists request on
the subscriptions page.
(imported from commit 76eca95b952c4b60e583a050be711023ee5fedac)
Make sure they still stand out against the grey background.
It's less clear that we should do this for private messages as well, but it
seems fine for now.
Fixes#658.
(imported from commit 4c750208b5f2697e91c1c4fa7365d2744260c6f2)
Prior to this commit, if you have the composebox open, pressing 'c' or
'C' clears its contents. This change makes it work more analogously to
pressing the 'New stream message'/'New private message' buttons.
(imported from commit 3de5bf83754d8ab86b1967ce2ba15f5846090667)
As it currently stands, after the introduction of operators, narrowing
to messages that contained X would also trigger a find-in-page.
This stops that from happening, and then also makes the default action
of the search-bar-invoked-without-a-typeahead be 'narrow to messages
containing x' rather than 'find in page'.
(imported from commit 1beffce426c6b00449e7c1c803687a129747ed63)
This is a tricky one because it's kind of hard to see locally, but
there's a bit of a delay between when you click "Invite" and when we
get back to you. So we give the button a "loading" state so you know
not to click again.
(imported from commit 9c3389a3d06def777427c846d6106f6d9b30cc8b)
Leo points out that if you type a stream name, we probably want
to offer to narrow you to that stream more than we should offer
to find that stream name in the page.
(imported from commit 803ac681ec2f759f4dabb68a40722a07b86a0cab)
On my laptop, this cuts search time from several seconds down to
a few hundred milliseconds.
If we want even more speed, we could store the ts_vector as a column
on the message database. The Postgres documentation says this will
make "searches [...] faster, since it will not be necessary to redo
the to_tsvector calls to verify index matches." Going this route
requires creating a trigger to automatically insert the appropriate
column when new rows are inserted.
Note that the full text index must be fully created before this
commit is deployed. Full text search without an index is actually
significantly slower than using the LIKE operator.
(imported from commit ae74083da20d33aa2425d3e44fcdc19b160002ba)
This schema migration is only for use in automated migrations. To
deploy on the production database (the migration only needs to be
done once for both of staging and prod because they share a
database), you should instead execute the following SQL manually:
$ ssh postgres.humbughq.com
$ psql
humbug=> CREATE INDEX CONCURRENTLY zephyr_message_full_text_idx ON zephyr_message USING gin(to_tsvector('english', subject || ' ' || content));
Note the addition of the "CONCURRENTLY" keyword. The problem is that
creating the index takes non-trivial time and requires a write lock
on the table while the index is being created. This would mean that
users would be unable to send messages while we were generating the
index, which isn't acceptable. We can't create the index
concurrently in the South migration because concurrent index
creations can't happen inside of a transaction and South forces a
transaction on migration functions.
Also note that this index must be created before Postgres full text
search is deployed to the app because full text search without an index
is actually much slower than plain search using the LIKE operator.
(imported from commit 8b9445c27d0e427278de997b22342bffe6d855b7)
This is for allowing us to do things more complex than returning a Q
expression, needed for doing Postgres full text search.
(imported from commit 669ec71417c04baaf8ed1774bee147079b05b03d)
We will minify our code, rather than trying to restrict who can see the
un-minified code. Removing access control first simplifies things.
Manual deployment steps:
scp servers/puppet/files/nginx/humbug-include/app root@staging.humbughq.com:/etc/nginx/humbug-include/
ssh root@staging.humbughq.com service nginx reload
and then the same for app.humbughq.com once deployed to prod.
(imported from commit 63788aa3fa7ba5fd97fcf85b05760abb5e7cae4b)
1) Make the search hotkey (/) no longer clear the search box
2) Vertically center the "Search..." placeholder
(imported from commit 02dee6b72c4457e160f57d8604164e15e62f5f28)
This fixes Trac #723 - Message view scrolls to top after reloading on another tab (e.g. settings)
(imported from commit d9134cec6879625d577c43a08d258af3f6dacc5f)
Supporting ``` as a code fence marker complicates the auto-fence
closing, and as per a discussion with Keegan on code-review@, it
is not worth the extra complexity.
(imported from commit 405afb95c4295a02f4677181456caf9d49913ac4)
We don't use the latter anywhere in our API, and this typo caused user
API keys to be emailed / humbugged places.
(imported from commit d0402e8e9fd587f6a9018c962d222fb5f9ceca48)
Under some unknown circumstances (it happens on Keegan's laptop) the
loading indicator text width calculation returns a result that's a
few pixels too small. We hack around this by setting 'white-space'
property on the container div to 'nowrap'. The container's div will
be slightly too small (and thus the text will stick out the right
side by a few pixels), but that's probably OK.
This fixes#698
(imported from commit 2e5b28fb3a1fca78c700af74a452bfafd09a2da9)
This is to make the loading_indicator_text height closer to
loading_indicidator_spinner's height.
(imported from commit 062973e9c09b005601c5c943ce65dc97eeee179f)
This should fix the weird positioning spinners had when they were
created while hidden.
(imported from commit 777d5c376a3f93b0b7b3b749877070b438b7c102)
This changes the sorting for autocomplete to:
* Properly prioritize case sensitive and insensitive prefix
* For recipients, prefix-search on email, then sort by most recently sent pm
(imported from commit 893c7a07d678644a418a69656180fadf0d6f374d)
The fact that the user sees a change (the button changes or a row
appears) makes it obvious that the operation was a success. The
success messages were only serving to make the page scroll
confusingly when you couldn't see the top.
(imported from commit 471b9304f71bb8533c98d208b855d4d75c04a886)
The query fails anyway, so this is not a safety check. This commit
makes it so that MIT users actually see their subscriptions instead
of an error.
(imported from commit ee635943728d7d9823e118d9fa51c402b1cd9bf2)
We now keep around the subscription information for streams that the
user unsubscribed from in stream_info and have a field that
indicates whether the user is currently subscribed.
(imported from commit 973e2f4bd4139157b03d7c1a372db93a1a5130f7)
Trying to add a user to an invite-only stream that already
exists will result in in error
(imported from commit 910750580a122cee92096d7e83457cb0b8cce616)
Previously it was just testing that sending a GET request to our
POST-only URLs returned a 400 error.
(imported from commit a510734271385046bbf29166b38c0ecbd104d2da)
If get_updates requests a message ID that is too old, Tornado will
return a 400, and currently the only way to start caring about newer
message IDs is to reload.
(imported from commit 1638d71868475ffd793162afc7a2731cab14bd75)
Longer-term this should be done in a more sustainable manner, i.e.
including Glyphicons like we currently include Halflings.
(imported from commit 3f405c969352481626614a0d61874bd77f0388b7)
This commit both causes the settings button not to be drawn as
pressed, but also fixes the issue we were experiencing where,
e.g. changing from "Home" to "Settings" and back to "Home" would cause
you to lose your place.
(imported from commit 5084b280a202f6bf8f811834bf9d2734a034c8c1)
This is really the first step of implementing the "Oppa Gmail Style!"
redesign, and is largely an HTML/CSS-based change, with some
slight JS tweaks to deal with things being renamed or being no
longer necessary.
(imported from commit e05adc283ea066f0f90009cf712c4f3657c2485a)
Prior to this commit, at <979px, the .container in a .navbar has
`width: auto`, but a normal .container has width 724px, which causes
the two to drift out of sync.
This fixes that.
(Arguably, it's weird for us to waste ~200px scrunching
this down to 724px at this ratio, but we can solve that
as a separate issue later.)
(imported from commit 1f431ca1e2168db75821ea0be43941d29fd3e6b8)
We always want the navbar to stick at the top, no matter what
the screen size, and we want it to consistently look the same
height, etc. regardless of our page width.
This is possibly also accomplished via position: absolute !important
and other overrides in our own CSS, but this actually seems
slightly cleaner in a way.
(imported from commit 340fafb49bcbc1088a816897d320e252c4615d19)
Some time between the 2.0.4 and the 2.1.0 upgrade, Bootstrap broke in
a way such that clicking on a dropdown did not cause it to close.
Here's the bug thread about it:
https://github.com/twitter/bootstrap/issues/4497
I've implemented this workaround discussed there, though the bug is
fixed in 2.1.1, so when we upgrade this will go away (which is why I
only reluctantly tag it 'third', since the diff will not need to be
carried forward.)
(imported from commit f8d9cf65b33306a426d864c9b503bb3446614111)
Apparently short_name is not consistently the person's username
in our system -- for many MIT people, it's their full name.
(imported from commit d975300a59c7afe5ee20b4a0db1bd51110c3df33)
As of this writing, short_name is the part before the @-sign,
and we already display the realm, so no need to display it
twice.
(imported from commit f5f9b29bff99b36b0c23176348c2869193467c38)
This should fix the issues we saw where users who hadn't received a
message in the cache would not be able to receive new messages.
(imported from commit 3834dd5bd5a10c7a603194b540d78afd8a966017)
When not in lurk mode, lurk_stream is undefined which caused
lurk_stream.toLowerCase() to fail.
(imported from commit 63ce79083b55a37cb0455871237a76d724fbbbea)
Eventually there should be a database table or something where we can
configure this for each realm.
(imported from commit 5f3e6823f420e113da8ff8c521cc706175299fa4)
This is needed for the next commit so that the loading indicator is
created while its associated div is visible.
(imported from commit 72d6ccc14158b49e0ea640ab818114869aa548bf)
This is a hack to work around the fact that the query here takes far
longer than it should.
(imported from commit e6ee00c0636fe85cd946e4e3f2bbb2bda2da1f26)
The stream message cache query was grabbing an overly broad set of
columns and related models (e.g. the sender's user_profile), so that
Tornado would spend too long doing the query.
(imported from commit 6a692bc0e31957d4b9d9528d348c4b07a09eb15c)
As a side-effect of customizing the e-mail, this also makes the host
on which the error happened a part of the subject line.
(imported from commit 7d5e9ad108b48fd34528512c5955567119935d4e)
Prior to this commit, they weren't able to subscribe or unsubscribe
from streams or change stream colors.
(imported from commit 7f690c724bec3e7e6ba3b45ac7b41d1f7296b6f1)
If you create a spinner in a hidden element and then show the
element, the spinner is placed differently than if you had created
the spinner while the element was visible. This commit makes it so
that we never create spinners while their parent is hidden.
(imported from commit a21e68976d70fcceece30ee35f5e7cf6f9490497)
This allows us to use a uniform style across all our spinners. It
also cuts down on boilerplate HTML.
(imported from commit 9879f38e0f1ca8edd40a937753811e329447262d)
/?lurk=foo will show all messages to the stream "foo", regardless of
whether you're subscribed.
(imported from commit 049d98b3ee8df19ef0a9dc392ae941dd463f8dd5)
A public stream is one for which any user can view all messages sent
to the stream, regardless of whether the user was subscribed when
those messages were sent.
For now, to avoid a database schema change and to facilitate testing,
public streams are all streams on the customer29.invalid or
humbughq.com realms.
(imported from commit 7a71fd788d585a6f5b3e494e771ec85b632bb36e)
Before, a whitespace-only search would "highlight" the pointer and all kinds of
other interstitial space, which totally broke the page layout.
Fixes#408.
(imported from commit e7e0e251551a9da5a2ea53e36b9cce16e3e30634)
* Ignore beginning and ending whitespace when submitting the form
* Ignore beginning and ending whitespace when doing autocomplete
* Don't autocomplete on just whitespace
(imported from commit b3231e08f6797a38bafbcef2e694f4bae059c20f)
Right now we mitigate abuse by sending the principal user a Humbug
informing them that they've been subscribed. Longer term, we want
some sort of stream invitation system, instead.
(imported from commit bf1f1ee0c5d3803cead1ddd9a766ff02043b629e)
The production database will need to have this user created before
this commit is pushed
(imported from commit cc8356d8afa0f0747486b7b4c82337c60499d3fd)
We need this so that we can safely expunge old events without interfering with
the running server. See #414.
(imported from commit 4739e59e36ea69f877c158c13ee752bf6a2dacfe)
So that it is, in fact, navigable via keyboard shortcut. It's not the
most beautiful way to do this; in the ideal world the layout would be
more properly responsive and could fill up the screen for you when you
have the room for it.
The issue is that the version of Bootstrap we're running doesn't
easily allow for variable-sized modals, and the hassle of showing
and hiding a div manually didn't seem worth it.
The pixel sizes are specified manually as well, in a way that
isn't particularly responsive, because of a few competing
desires:
1) For them to appear side-by-side when wide enough
2) For them to stack when not wide enough
3) The fact that they're awkwardly between a span2 and a span3,
so we can't just use the Bootstrap responsive layout stuff
Finally, the diff here is best viewed with -w. (I also swapped the
order of Narrowing and Navigation, which unfortunately clutters the
diff.)
(imported from commit 62cfa7959d48ce515562713eb48f9d9b33c8cc16)
Before this is deployed, we need to install rabbitmq and pika on the
target server (see the puppet part of this commit for how).
When this is deployed, we need to start the new user activity bot:
./manage.py process_user_activity
in the screen session on the relevant server, or user_activity logs
won't be processed (which will eventually result in all users getting
notifications about how their mirrors are out of date).
(imported from commit 44d605aca0290bef2c94fb99267e15e26b21673b)
I'd like to phase this out in favor of something you actually
see only when you don't use Tab-Enter, but that's more challenging
than I'm prepared to tackle right this second.
(imported from commit eeda53b0ed69d0e528b00ea9e7c7a20edb35df34)
If you're currently composing a message and you click one of those, it
now no longer clears out your old message contents, making it more
analogous to the job the old selector used to play.
(imported from commit b935a3bf307bdbd82f1ee7db31d3a3c89c623195)
Accomplished by:
- Hiding the stream/PM selector
- Eliminating the "tab to send" reminder
- Moving send and formatting links to the right
- Reducing the size of the 'subject' box
- Generally tightening up whitespace
To be fixed later in this series:
- A Tab-Enter reminder
- Completely eliminating the stream/PM selector
(imported from commit 7efe04adcbe373f99a36d3ba23b32944c17aa099)
internal_send_message now has the ability to send personals as well as
stream messages.
This change was accidentally lost during a rebase.
(imported from commit 153a3929c5c64be82288293c1f0cc02fcc03c08d)
Later, we can fork off a separate process to do that task, but for
now, we can just rely on the fact that unless the server was just
rebooted, the relevant messages will already be in that cache, and
even if it was, getting the needed messages once each is not a
particularly expensive query.
(imported from commit 6d08eba1b41237fd4e1204e181ce8f227573930d)
It can easily cost an entire line, and the information is available by
clicking on the sender's name. Plus on a phone, you can't hover
anyways.
Annoyingly, this tends to put the popover partly off the window, but
there must be a way to fix that separately.
(imported from commit 19334cb067981b323e300245654c83c8e545fb2e)
It's possible for selected_message_id to not exist in zhome. For
instance, when you open the page to a narrowed URL, there is a race
between loading the narrowed messages and loading all your
messages. If the narrowed message request completes first, it will
update selected_message_id to your initial_pointer if the latter
happens to be among the narrowed messages. Even if it is not, you can
select a message by clicking on it before the zhome request finishes.
Then the old code would never add that selected_message_id to the
zhome table, so it wouldn't show up in the Home view or if you
re-narrowed.
I'm pretty sure there are still cases where the selected_message_id
might be outside the range of messages in zhome, in which case adding
to zhome might put old messages at the bottom. I observed this twice
on staging but was unable to reproduce it consistently.
(imported from commit 162feff3090f8806cc67140db0cfabb6e965aece)
The schema change made this no longer a guarantee, and creating duplicate
PUs is not harmful.
(imported from commit ca05b4dad7d3cc12a35548817f98c0a072c14c8f)
This involved splitting off into a separate function the second step of
the two-step registration process.
(imported from commit bd1ec9b5abb15d29b0585873daaa54a8d4e26556)
Added field invited_at on zephyr.PreregistrationUser, with a one-time
default of Jan 1, 1970 for existing objects.
Added M2M table for streams on zephyr.PreregistrationUser
Deleted unique constraint for ['email'] on zephyr.PreregistrationUser
(imported from commit 85247acb488201f8fc51dfaae354423c27eddcb0)
This allows us to handle the return_messages_immediately part of
get_updates requests without having to talk to the database.
(imported from commit ed0b7742d359efb21a0a4960f4fc25f4337e9ad4)
This commit has the effect of eliminating all of the non-UserActivity
database queries from the Tornado process -- at least in the uncached
case.
This is safe to do, if a bit fragile, since our Tornado code only
accesses these objects (as opposed to their IDs) in a few places that
are all fine with old data, and I don't expect us to add any new ones
soon:
* UserActivity logging, which I plan to move out of Tornado entirely
* Checking whether we're authenticated in our decorators (which could
be simplified -- the actual security check is just whether the
Django session object has a particular field)
* Checking the user realm for whether we should sync to the client
notices about their Zephyr mirror being up to date, which is quite
static and I think we can move out of this code path.
But implementation constraints around mapping the user_ids to
user_profile_ids mean that it makes sense to get the actual objects
for now.
This code is not what I want to do long-term. I expect we'll be able
to clean up the dual User/UserProfile nonsense once we integrate the
upcoming Django 1.5 release, with its support for pluggable User
models, and after that I change, I expect it'll be fairly easy to make
the Tornado code only work with the user ID, not the actual objects.
(imported from commit 82e25b62fd0e3af7c86040600c63a4deec7bec06)
Otherwise one gets:
AttributeError: 'module' object has no attribute 'time'
when trying to use the time module from inside zephyr.lib.
(imported from commit 645368672a3eff68320278dd480edeed56721fcc)
We suspect that these seem to be causing a regression where scrolling
in narrowed views gets really sluggish, but we haven't totally been
able to figure out why since it's challenging to reproduce locally.
(It currently manifests itself on staging but not prod.)
So for now we'll back them out. Here's the full set of things:
Revert "Cause update_floating_recipient_bar to get called less frequently."
This reverts commit a6c1518c4001a2dde44d7b512236795da3ccd351.
Revert "Remove double-scroll in un-narrowing code."
This reverts commit 3dde6c27ffa1e8afa1a084b1b2baee3bc0512962.
Revert "Reset our scroll position if we change our hash to "#"."
This reverts commit 925b44d770c96dafaabebc9e0114f9a3b8f53c4d.
Revert "Properly update floating subject bar when you are at top of page."
This reverts commit 6633cc8a81aedcbb31b30d7c1f27816f8808c700.
(imported from commit a273730581cef30c33bedf701659ee084434f8ad)
Note that on local dev servers, this will print out every half second, as
Tornado polls for file changes for autoreloading. In production it will only
print out when network events occur.
(imported from commit adfe88879e4e446b7dfa6ee69e0a9ad013e9c4d4)
This should remove a database query invoked from Tornado by our
decorators in the common case.
We use hashlib.sha1() on the key because memcached doesn't support
keys with whitespace in them.
(imported from commit 351ef4c76bc68e2d53f0e7ddca91dcf95e7bb2a6)
Previously it wouldn't work due to using the wrong port numbers.
This commit also has the side effect of fixing the fact that our
frontend tests would send real emails and log events to the real
message log.
(imported from commit f2cf400e6061c089627acba2759d588981ecf5bb)
This should save a database query when we later need to access fields
such as the user's realm name in format_updates_response.
(imported from commit ceef726db9e917cfb0b47061130d7299ee64890d)
This code is from a previous protocol where the users array was posted
as a comma-separate list, rather than encoded via json.
(imported from commit 3a2edfcbf250a7eef305b2e98018c1361cc2fffe)
This is for consistency with the rest of our code dealing with message
delivery, which always uses the user_profile_id.
(imported from commit 5bf10bb9b994b0a98d3a22bd0bd86e542ab8a2ee)
Putting update_floating_recipient_bar in the old location caused it to
be called on every single keypress, which is unnecessarily
expensive. Instead, just call it once when we think we might actually
need it: after initiating a narrow.
(imported from commit a6c1518c4001a2dde44d7b512236795da3ccd351)
Watching new users, I've seen them not notice the pointer and
mix. Give them a little more hinting about what message is selected.
(imported from commit c98e22dcef881ed7400071ec438a6e91d6cd3d9e)
select_message_by_id with then_scroll: true already recenter_views
on the selected message; no need to also call scroll_to_selected.
(imported from commit 3dde6c27ffa1e8afa1a084b1b2baee3bc0512962)
Changing the hash to "#" causes Chrome to jump to the top of the page
on Mac OS X. This commit doesn't actually fix any bug, but it
is necessary for my *next* commit, where otherwise you'd have to
ensure that the scroll code came *after* the hashchange code.
(imported from commit 925b44d770c96dafaabebc9e0114f9a3b8f53c4d)
There's this very edge-case issue which is: if you go to the top of
the page and narrow to something other than the top message, the
floating subject bar does not update.
Why? Well, the way that the narrowing code works is that it sets up
narrowing and then calls
select_message_by_id(target_id, {then_scroll: true});
so that our selected message is in the view.
This in turn calls select_message, which calls recenter_view as
appropriate. This usually causes a scroll action, which in turn causes
the floating recipient bar to be updated.
But when we're at the top of the page, recenter_view doesn't need
to scroll at all! So the bar remains un-updated. Here we explicitly
update it to guard against that case.
This fixes Trac #651.
(imported from commit 6633cc8a81aedcbb31b30d7c1f27816f8808c700)
I don't view this as a complete solution to
Trac #466 - Make the fact that you are narrowed more apparent,
but it's a start.
(I think a real solution would have to give you something that
helps you make the determination of "Is this view narrowed?"
when you come back to your computer, and this animation does not
help you do that.)
(imported from commit eb3646f3f3a4e25a43266e9146308633fd997eb2)
This commit just moves around some lines so that the code that
hides the main view and shows the filtered view, or vice versa,
are together so that it's easier to reason about the sequence
of things that's happening.
(imported from commit 7e99f45293c0e1a4cdfa1a08f41f8c770c370d6c)
This used to be a button that let us un-narrow, I guess.
A git grep for it after this commit turns up no actual
references to it.
(imported from commit 05acb4bb40da1b032f548c511fbae5b2b20874a8)
And change the color to a more thematically appropriate blue.
The shadow pointer is sort of confusing; we should really provide some
different sort of indication that your pointer is potentially moving
on narrow-and-unnarrow. (I think my fade-in-fade-out later in this
commit series is a not-bad first crack at this.)
Resolves Trac #472 - Dual pointers in narrowed view can be confusing
(imported from commit 2450517d99de85ade1c0e98c5510b59e70282451)
tornado.web already does this, based on the setting of the 'debug' kwarg.
Dropping this in production saves us waking up twice a second to stat()
a bunch of files.
We already explicitly restart the server on deploys.
(imported from commit 283bb0da609acb2699a04111a74c13224fe5124c)
If you narrow to a view that only has one or two message, sometimes
the grey box gets cut off and doesn't go to the bottom of the
page. This fixes that.
(imported from commit 55724d03aa30922d91bd33fab4447d889be78889)
CasperJS can't handle them; window.webkitNotifications.requestPermission()
throws a type error. We can revisit this when we want to write tests for the
notification code.
(imported from commit 90f4d6ac3ddb387e74051b9af2c230698fa94479)
We apparently cannot rely on Iago to consistently be subscribed to
"Denmark", so make this determination some other way.
(imported from commit 2a75b345c2d82097ab44538942af89536aac09ed)
Previously, if last was None, we wouldn't check dont_block,
server_generation, or any of the other reasons that get_updates might
return immediately, and just unconditionally entered longpolling mode.
In the process, this reorders return_messages_immediately to have
fewer cases and thus be easier to read.
(imported from commit 67803b8bfc7d9c9c1a4d6916eb2fb62664fb35a9)
This check was a workaround for the fact that the browser client
submitted a "last" value of -1.
(imported from commit a668f6a4e7a0c027f1214166a9bbf40d29b5daeb)
We shouldn't deploy this change until strictly after we deploy
"Fix website improperly submitting a last value of -1."
or we will break website clients.
(imported from commit 7f682ab0f7060b677f53f0a0073faef216f45d00)
This view lives at /accounts/accept_terms, and (after getting an acceptance
from the user) sends an email to all@ documenting the acceptance.
(imported from commit 8f64286ab02887fd6544fa274b2967f6499b6dbc)
So, I got annoyed that our test suite was taking forever to run:
real 2m13.443s
user 1m32.630s
sys 0m3.748s
Some quick profiling determined that the test suite is spending all of
its time loading the fixtures files (zephyr/fixtures/messages.json)
that it loads for each test case (3s to load that for each test case).
To improve this situation, I cut out from the test database used by
the test suite most of the users, subscriptions, etc. that aren't
being used directly by the test cases. The impact is a quite
significant speedup:
real 0m15.176s
user 0m9.161s
sys 0m0.508s
We're still spending over a quarter of a second per test, which isn't
great -- but this is at least no longer unbearable.
This commit doesn't make any changes to the populate_db output if you
don't pass the new --test-suite option.
(imported from commit 2334ba5399b33edab3d29ff269fde4ea77ccd48e)
The initial rationale for hiding the floating recipient bar
was that it duplicated information that was in the "narrowbar".
Now that this no longer exists, let's *always* show the
floating recipient bar.
(Yes, there is some duplication of this information in the
search area, but I think the situation is fundamentally
different now and would basically like to see it everywhere.)
(imported from commit 6fd4506c2f48caade9496139e580e6550252ce8c)
Apparently after you call waitForText, if you don't specify
a callback function, you need to put the next stuff after
a casper.then() -- not doing so caused some tests to fail
if, e.g. the subscription list did not load super-promptly
(because we checked for the text even before the waitFor
expired; in other words, we were not blocking on it.)
(imported from commit c71d543db0aba0c27b5136b92bb6e28e63278ac5)
Inspection of the postgres slow queries log showed that the "narrow to
personals with a particular user" database queries were taking a long
time to run (0.5s+). Further investigation determined that the OR
gate construction used here was causing the entire zephyr_message
table to be scanned; primarily I think because we were using the
implicit constraint that the logged in user had received messages.
This change makes that query explicit (improving performance), while
cleaning up the code to avoid an unnecessary query and read a little
more clearly.
After this change, the relevant database query takes 10s of milliseconds.
(imported from commit 020f5af5846c958386615e37ea9318383bf99ca0)
Alternatively the server could return a successful result with an empty list of
messages. But I prefer the solution in this commit, because it would allow us
in the future to warn the user about the problem. It does allow users to
determine if a given stream exists, but we haven't tried to hide that
information so far.
(imported from commit a91e12c90b12d3c870c0b637c3f1d6d3cef88491)
It's cleaner if the filtering code recognizes only one value.
We can add this back in by converting in the parser.
(imported from commit 453b7b01e094955c6d66be63b5d997cc56b50a35)
Show the buttons iff
- the search input is focused,
- the search input has non-empty contents, or
- we are narrowed.
(imported from commit f5c98471a2db4ab522160960dd1271471a9db555)
We don't require that the parsed form be lower case; that's handled by
narrow.activate. However we unparse as lower case, in order to give the user a
hint that matching is not case sensitive.
(imported from commit 2882b440deb59a049b095db7a13cfc18e047caec)
Also removed .show()s for the alert on does-not-exist and not-subscribed, where
a blank error would display. This should fix the underlying issue with #166:
that hiding the composebox before send_message() was called would hide server
errors.
(imported from commit a8a50cdf82ddf1d15f1e405432ff3bbfdb7a491a)
This is needed to avoid exceptions trying to do internal_send_message
in any test against a simple populate_db database.
(imported from commit 36927f57cbbb7e30ae249b5f1a0549fb352827f5)
If you have a lot of subscriptions that you're trying to modify,
jumping back up to the top of the page is very disruptive. We still
show the success message, which has the effect of scrolling the page
and is thus surprising, but that's better than the user completely
losing their place.
We do need a story for informing users about failures to subscribe or
unsubscribe, though. We currently jump back to the top so they can
see the error, but that's not optimal.
(imported from commit 48d938ddc47f286a72e2147f4459b91ca5684e36)
This reverts commit a590bf6b8ee733893d3410ecb5eebe54141c48ea. This commit broke
the test suite because it was not tested after rebasing with Keegan's changes
to the tests.
(imported from commit 7248a55328609973c5303be6c85eeb5fbfc1475e)
GetOldMessagesTest had test methods that weren't included in the test suite
generated by Runner because they did not have "test" in their names. A few
bugs in these methods that were overlooked because of this were also fixed.
(imported from commit a590bf6b8ee733893d3410ecb5eebe54141c48ea)
For debugging in case this is ever different from platform.node(). I
think this would happen when using a CNAME, for example.
(imported from commit 47f6c3490712a3ac1c6a16f9146c2ef3ca8fc5e8)
This essentially reverts d900957e468815bcb99de67d570dfd7ce4413220.
This code was consuming up to 50-100ms per client recipient of a
message, so for any messages that would go to 50+ browser windows /
mobile devices, it would take several seconds to run, during which
time Tornado would be completely blocked.
In the future, we can re-fix #174 using a cache of recently delivered
messages, so that this code block doesn't go to the database and thus
can run instantaneously.
(imported from commit bdfa1664210429411737f70cde54ab5a56525341)
For whatever reason, specifying a percentage for bottom_whitespace
seems to cause issues in some browsers, including Firefox 17
and the Firefox Nightlies.
This is a bit confusing to me, since bottom_whitespace is basically
immediately resized by resizehandler initially anyway. But hey.
(imported from commit 93da101edeb6f16b01a92aed775e9117c0295086)
CSS height percentage was not working because parent div has an undefined
height, so instead it is set to 40% of the window height on resize (and initial
load) via JavaScript.
Fixes trac ticket #24.
(imported from commit 2c6a8489585c4bf70c44469ce8628264ec3fbc36)
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)
Hopefully this will make things slightly more discoverable;
the previous solution (putting a prompt in the initial text)
was not that discoverable.
(imported from commit f6a7fce1bfd27bda412522768e981b2ffc39f474)
This fixes https://trac.humbughq.com/ticket/546.
It's a little unpleasant that this special-casing lives in hotkey.js
-- instead you could imagine doing something where there was a whole
special set of hotkeys when a search is active, like we do with the
composebox, but this gets the job and is probably simplest.
I would have written this as a case that just falls through in the
else condition, but jslint doesn't like that.
(imported from commit 65a1b8aa1efc356b6690dc177058a4fb9e12745a)
We previously were only using it at the first loop through all
messages, which meant code accessing the message type copied from one
place to another would break (potentially subtly), because things
would work if and only if the very last message happened to have the
same type as what is expected in the relevant piece of code.
(imported from commit ad9ce5efdb200e0c0d5c3ffa6db33113fdad8c5a)
This addresses Greg Price's feedback in #527. We now distinguish
between normal pushes, force pushes, and branch deletions.
(imported from commit 0fab6055f63ffc7e6df283b8bb8ed9971000e6d5)
This cuts a 30s operation down to about 2s on my machine.
And also move the code to run before we print the "done" message and
have logging for how long it is taking.
(imported from commit 2f20f8ca3fee714735a50fe6c6cfd630df452768)
This is syntax like
Here's [a link][]
[a link]: http://google.com
This is not very useful for short chat-style messages. It will confuse users,
especially because we don't document it. And disabling it saves the effort of
applying the same link fixups as elsewhere.
(imported from commit c23391465486db545302b79c084b4f9cd5cdcc6a)
Jessica McKellar
Luke Faraone
Keegan McAllister
Waseem Daher
Zev Benjamin
Leo Franchi
Tim Abbott
Jacob Hurwitz
Leo Franchi
Luke O'Malley
Jeff Arnold
Reid Barton
Tyler Hallada