Previously update_pointer POSTed the selected_zephyr_id, which in reality
was the ID of the zephyr we just moved off of, rather than the current
zephyr we just higlighted.
(imported from commit 2b143b34d3042a789b3f6a999117115dd6243782)
For some reason on both my and Waseem's local instances the lack of a
trailing slash was not an issue, but this does fix the issue on the
live site.
This could be because we are running Django 1.4.1 and the deployment
server is running 1.4.0.
(imported from commit 613732d75f204fd654247382088d92879780560b)
We no longer break random things! Its pretty grand, actually.
This reworks and reverts commit fbadd6e854722e41cccd2535748ee47f4efd657b.
Conflicts:
zephyr/static/js/zephyr.js
(imported from commit 534a120290855d3bf2cf979ac174267c2d07bf68)
For now the idea is that if you're in the search view (or the
subscriptions view) and you click 'New Message', we should
snap you back to the main view.
This may or may not be the right behavior in the long term.
(imported from commit 43c24e1af9e80225ff9be8a62f4c8c925960436a)
This corrects some additional bugs introduced in 9128ddd and a5f06bd
identified by Keegan.
We previously used "for i in"-style looping, which is sub-optimal. Move
to a different style.
We also had a weird spacing thing I introduced in a previous commit,
which has now been fixed.
(imported from commit 7334d8ee703564bedeb0ea939b0d64ad2d5fceba)
Previously we were iterating through all zephyrs twice on the server, now
we are moving part of that to the client so the client has an index of
Zephyrs that it generates itself as part of add_message.
(imported from commit c07a6c36911fa2eae6f216c34331be34b2aa8178)
This was copied from a Bootstrap example page and is messing up the topbar on
login, subscriptions, etc.
But I like the padding on the main view left side links, so we'll keep that.
(imported from commit 67ef75a7a0f359d0f2bc2857e56aa2249ec09cbf)
Previously, when trying to send a zephyr to a new class, you would
actually send N zephyrs, where N is the number of times you'd created
a new class.
(imported from commit 2c36b0282c8c2291e05b5ad952f5b25e3f43d406)
Also strip leading and trailing whitespace, so 'Bar' and 'Bar' aren't
separate classes.
(imported from commit a39c220d1a4c4d179f4adbf5e1391436eda32f4f)
You don't care about that content anymore. We probably want to clear
even more aggressively than this.
(imported from commit 29f6910a12e1b722f5801db644b04f54cf5bfd63)
I still don't love it visually, but it's getting there.
Some obvious issues:
Personals window is totally unstyled
Clicking 'new message' should perhaps give you a fresh new window
not something prepopulated with old stuff. Think about this.
(imported from commit 8b28fd084d550db404eabbe63c056fa6866c0697)
Put a little 'x' by the class or class-instance indicator, to make
it more analogous to the planned behavior of the view-in-context
search box.
(imported from commit fa01001cffa6a6094ba5fbdcbdc965addb2efa1c)
Previously we would extract zephyr data from a TR. In the NWO where
sometimes this data is ommitted, we instead need to use the zephyr_dict
object.
(imported from commit a5f06bdadc4fbe13f1718d6dcb41046d0ed040cd)
The purpose of this is to ensure that we can reference a zephyr by its ID
and get all the data about the zephyr; in the future we may not have all
such data stored in TRs as we do now.
(imported from commit 9128ddd01b46396fd276124ca1e6430538d3dd63)
Today I'm of the mindset that searching is a fundamentally
distinct operation than narrowing, so this reflects that.
(There would be a separate screen and UI for searching,
I guess.)
(imported from commit 432a4088612dafd06184bec228b63056961325dd)
unhide -> show_all_messages
narrow_indicator -> currently_narrowed_to
narrow -> searchbox
This is a little clearer about what these buttons/functions
do, which will be useful as we add a little more complexity
associated with searching.
(imported from commit b51e745ea71c212d6735e04011eaea5e71bf6d5a)
I'm not exactly sure that this is the interface we'll want for
this, but it's the start of an experiment.
(imported from commit ea18a9b05106546475bc151229955ddafd8e7b8e)
This looks ugly, uglier than the alternative, but I want
to encourage us to figure out how to deal with this case
rather than allowing it to wrap.
(imported from commit 9ef9cedeca2e27a0db996083e2e528f3daec3f43)
Setting both max-width and min-width really feels like
a hack -- surely I can just set "width" and be done
with it?
(imported from commit 7650419c5ae8bb7ce3a3d6bd7dabbfb42390586f)
We'll eventually need to normalize emails, autocompleted names,
etc. to one entity we use when talking to the server about senders and
personals recipients, but for now since we've hardcoded usernames
everywhere, just use those.
(imported from commit 4a0e033b301b8dec55d97157eb4993982f6b2641)
I have some serious concerns with this implementation,
but I think it's still an incremental improvement.
(imported from commit 6ed8d2545c727e25bf85b98a1528dbf3d155bc92)
This reverts commit 8c47682cd80fec0d221a519abc593f4d83dc90b5.
I accidentally broke.. a lot of things in my last commit. Lets fix those
issues before pushing to master again.
(imported from commit fbadd6e854722e41cccd2535748ee47f4efd657b)
Eliminate huge left margin, and don't let long class or instance
names totally break the layout.
(imported from commit 69237d29a60241bdadda0469c4e08aa1d987222a)
This is mostly working; things that need to be implemented:
- Ask users for their Real Name
- Personal replies need skinning
- Miscl UI changes to match mockups
(imported from commit 3638cf5ec2ba2306004ba6db6fa4c25c47f76517)