Features:
* Only shows messages in the narrow
* New messages in the narrow will arrive as they are sent
* Works even for streams you're not subscribed to
* Automatically subscribes you to a stream on send
* Doesn't update your pointer
* All searches etc. automatically have the narrow added
(imported from commit 2e12b76849f6ca0f53dda5985dad477a04f7bbac)
Make sure that principles is a list a of strings (unless it
is None). This includes a unit test.
(imported from commit c2e3f1c0cafc207ceca67d5a174ef4e29a32c6ca)
This will allow us to substantially decrease the server-side work that
we do to support our Mirroring systems (since the personal mirrors can
request only messages that user sent) and also is what we need to
support a single-stream Zulip widget that we embed in webpages.
(imported from commit 055f2e9a523920719815181f8fdb44d3384e4a34)
As far as I can tell, we don't actually use this value, but better to
have it be clear.
(imported from commit 3655b87f28b0554ee3db0acb2c0d59543dd093a1)
This replaces the AppleDeviceToken table with a generic
PushDeviceToken with a `kind` field to make it easier to add functionality
like per-device/per-stream settings that share code between Android and
iOS devices.
The schema must continue to work on prod with the old table name, so we
add the new table in parallel and can drop the old table once this code
hits prod and any necessary data is copied.
(imported from commit 0209a7013f2850ac6311f23c3d6f92c65ffd19e3)
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)
I'd also like to add a database table to actually store the values
that we get out of this and our send message requests for future
inspection, but for now, grepping logs+statsd is good enough.
(imported from commit 99ef179651850217fe6e82c5e928d122ca91101e)
Now that we support email aliases, we have to be careful when going from
an email address to a domain that we assume we can use to get a Realm
object for. When we care about the Realm's domain, we want to follow
any RealmAliases that exist for a certain domain.
When we just care about the original email address domain itself,
for comparison or other purposes, use split_email_from_domain
This removes the ambiguity of having to decide when to use
email_to_domain + RealmAlias or just email_to_domain
(imported from commit 0e199495502d946ce2e1aae56263e7e8665be4ed)
Until we can add a banner to help users subscribe, it may be confusing to
narrow to a stream where you are not subscribed.
Partial revert of 390bdef
(imported from commit ea75fc59b979589b975465a3fecffea0f014fcf6)
It's a little weird that these still open in a new tab, but it might
be best to keep them consistent with all other links?
This is a first pass on Trac #1927.
(imported from commit 390bdef790a83af4240ad5f5a82e572ef5824756)
If authoritative data is available from say the LDAP database, we now
ignore the POSTed user name, and don't offer it as a form field.
We fall back to giving the user a text field if they aren't in LDAP.
If users do not have any form fields to fill out, we simply bring them
to the app without the registration page, logging them in using a dummy
backend.
(imported from commit 6bee87430ba46ff753ea3408251e8a80c45c713f)
The latter doesn't depend on the former; we can still fill in your full
name even if you didn't authenticate via LDAP.
This commit requires django_auth_ldap to be installed. On Debian
systems, you can do so via APT:
sudo apt-get install python-django-auth-ldap
On OS X, use your favourite package manager. For pip, I believe this
will work:
pip install django_auth_ldap
django_auth_ldap depends on the "ldap" Python package, which should be
installed automatically on your system.
(imported from commit 43967754285990b06b5a920abe95b8bce44e2053)
This should address user reports of huge bankruptcy counts even when
they are relatively caught up. The root issue is that we sometimes
don't mark messages as read for some reason.
(imported from commit 8799305a8665f9ee239575e6e95f603f89c1d427)
UserProfile.show_admin was intended to be a check for users that have
administrative rights in other realms, which we've harmlessly but
erroneously been using to check if they are an admin in their realm.
Use the more straightforward check instead, with a more intuitive
name.
(imported from commit d81050c7dbbb19e59c5e31750be303a4630e1456)
This fixes a problem where the desktop app would attempt to load
https://zulip.akam.ai:8888/ after authenticating the user, which fails
with CSS issues.
We should probably, separately, change our Django-under-apache to only
serve the one URL that it needs and redirect the rest back to
Django-under-nginx.
(imported from commit 3e3251863618269790f61b371e88af57b6cfb272)
Errors are sent to a queue processor that posts them to staging,
just like the feedback bot.
(imported from commit 4a8d099672a1b3e48a8bc94148d8b53db73d2c64)
The /avatar/<email> URL redirects to the appropriate
avatar URL for an email, whether it's hosted by Gravatar
or Zulip. (This will work even for external users, as
it falls through to Gravatar.)
(imported from commit 7e6f226659cb2e5a7f6426da0be8aa9bae9cff14)
Jessica McKellar
Leo Franchi
Tim Abbott
Steve Howell
Luke Faraone
acrefoot
Kevin Mehall