URLs with a realm of "unk" will be queried against the new bucket to
determine the relevant realm of the uploading user.
(imported from commit 5d39801951face3cc33c46a61246ba434862a808)
Otherwise the user_profile.backend attribute doesn't get set. I didn't notice
this previously because on first register authenticate() gets called, and then
the UserProfile object gets cached. This means that subsequent logins work just
fine as long as the UserProfile object is in memcached.
(imported from commit 834d95c46aa07724ea84802f09b7249de99b5ca8)
CUSTOMER16 wants their employee realm to:
* only use JWT logins
* have name changes be disabled (they want users' full names to be the
their CUSTOMER16 user name).
* not show the suggestion that users download the desktop app
(imported from commit cb5f72c993ddc26132ce50165bb68c3000276de0)
We currently expect the use of HMAC SHA-256, although there shouldn't be
anything preventing us from using other algorithms.
(imported from commit 354510a0b7e9e273d062a1ab5b2b03d4a749d6a3)
We can't just check that the realms are the same because ist.mit.edu is an open
realm and uses @mit.edu email addresses.
(imported from commit 7dbaa81cea6e4f82563dfc0cfe67a61fe9378911)
Adds APIs edit a bot's default_to_stream, default_events_register_stream
and default_all_public_streams.
(imported from commit c848a94b7932311143dad770c901d6688c936b6d)
Support setting default_to_stream, default_events_register_stream, and
default_all_public_streams during in the bot creation API.
(imported from commit bef484dd8be9f8aacd65a959594075aea8bdf271)
Allow bot owners to set which streams their will receive events for
without needing to change a configuration file.
(imported from commit 2b69e519dbc12ffbdba072031a7f7196c9e50e33)
This allows bot owners to configure which streams messages are delivered
to without needing to change webhook URLs or configuration files.
(imported from commit 32a0c26657c145b001cd8cb3ce0a0364d48902ce)
Github flags pushes as either `forced` or not. However, it always marks new branches as
forced pushes--but we don't necessarily agree with them. This commit checks for the `created`
flag as well.
This resolves Trac #2346
(imported from commit 960bd3ad707a4d1ad431e21dcd79389e8d4b297b)
This includes removing GET support for the endpoint, which is unused
and doesn't map well to this being a bulk endpoint.
(imported from commit 348ff9dfa84be1661368c6d7d35aebf2ae2a9ae0)
They have weird properties like not sending anything for unchecked
boxes, which makes it hard to wrap a client-agnostic API around.
(imported from commit fef73a57a55b218b55dab6be3453dd6eac73c789)
If we call exclude_muting_conditions() with a non-stream
narrow, it will now include a condition to exclude streams
that are not in your home view. As of now, this code only
executes during testing, but it sets the stage for doing
better in:home queries on the back end.
(imported from commit bbd764bd0e9588a50e4a82c915e82a2c1b99d73e)
If we are already narrowing to a stream, then we can disregard
muted topics in all the other streams and create a simpler query
for the DB to execute.
(imported from commit 35a074a76eec99922034a381741355da3fdd5b39)
Due to the way we store muted topics, it is possible that a
muted topic stream name may no longer exist, and we need to
handle that case gracefully.
(imported from commit 4d18ec55e45213657a67e160848229678f212765)
Previously, we assumed that num_before or num_after would be always be non-zero
after adjustment for the anchor. However, we don't adjust num_before or
num_after when a narrow is specified.
(imported from commit 9239fef140e109b11bdfbeef42e9fbed78660ad1)
All usages of json_to_dict were replaced with the check_dict
validator. The check_dict validations can eventually be
extended to validate the keys and values of incoming data,
but now we just use check_dict([]) in all the places where
we had json_to_dict, which means we aren't checking for any
specific keys; we are just making sure it's a dictionary.
(imported from commit fc5add9a7ef149dfac2a9a6d9a153799c4c0c24d)
Behind a feature flag you can now do searches like this:
-pm-with:othello@example.com is:private
The "-" in front of "pm-with" tells us to exclude messages
with Othello from our search. We support "-" in front of
all operators, although the behavior for "-search:" and
and "-near:" doesn't really change in this commit.
Note that the filtering out of "negated" predicates only
happens on the client side in this commit. On the server
side we ignore negated predicates and send back a superset
of the results.
(imported from commit 6cdeaf32f2d493fbbb838630f0da3da880b1ca18)
This commit doesn't change any functionality, and it is
designed to make diffs for upcoming changes related to
negated conditions a bit easier to read. This diff
looks a bit noiser than it really is due to some
reindentation of continuation lines.
(imported from commit 64c1cba98faa4bad4eaad122dd3de119caa880c0)
The narrow_parameter convert now converts tuples of
(operator, operand) into dictionaries so that downstream
functions/classes deal in dictionaries. This
affects get_old_messages_backend, messages_in_narrow_backend,
and NarrowBuilder.
(imported from commit 7e8cb887f7872ec687acd8c4857d1d5222ab0d5f)
This implementation is somewhat hackish in large part because I think
we're going to be wanting to redo the get_old_messages API somewhat
soon, and this may naturally become a lot cleaner as a result, but
this isn't a lot of code and fixes#2235 part (A) and substantially
mitigates #1510.
(imported from commit 47a2160a44befa9d83190c5cc95b90e92cc5b4cc)
This helps our iOS app when authenticating via Google Apps, since we
don't get the users' email address when we get the ID token from Google.
(imported from commit 066639958c1e8f7845505ebdabc37282defca5c5)
Instead of having home() set page_params.realm_name directly from
the user_profile object, have fetch_initial_state_data() set it.
This is more consistent with how we treat other data, and it protects
us against a race condition where realm name updates arrive during
the DB fetching.
(imported from commit 545e3bd73f150438126e3f941e9bebc7aa1d0614)
Apparently (according to our error logs) it's possible for there to be a "position" but no "line" [number]
on a commit comment. According to the docs, line numbers are deprecated, although they're probably
more useful than diff line number (aka 'position').
(imported from commit d48f9efbe42293c9585442bd521b1843042eca65)
A description was added to the streams and it is now displayed on the
subscriptions page. It can not be set in the UI yet.
(imported from commit 81d08b65eee42dba87cd99dd5bd30106c4eb6c6a)
This matches page_params.unsubbed_info, plus it sets up to
add something like page_params.stream_dict without being confusing.
(imported from commit 2d40deb779e5c7a488d6952560b4119094bbc0d8)
Before deploying to staging, create the tutorial bot:
email: welcome-bot@zulip.com
name: Zulip Welcome Bot
(imported from commit 2f337a00ffac888b121975bdb95a89cf2f8ab3a7)
Refactor github webhook to handle multiple payload verions
split github fixtures into v1 and v2 versions
Group together all realm-specific logic. When v2 becomes available, we can
ask someone in each org to make the changes via the Github Hook configuration, and
slowly remove the special cases.
TODO: when our pull request for github-services gets merged, the integrations page
should say to look for Zulip instead of Humbug
(imported from commit 4790a730010b37186640f9996291afa6e8f96c2b)
Add a test sending new stream notifications to realms with a
notification stream and fix a bug in building the subscribe button
markdown.
(imported from commit 37985d8c0603ae206bef34b9522231c00bc8c572)
When new streams are created we now send a message with a custom
markdown tag that renders a subscribe button.
(imported from commit 9dfba280b3b4ff4f32f6431ef9227867c8bf4b40)
Normally github gives us a past tense version of the action, but
not for "synchronize," so we fix up the tense.
This also adds zerver.GithubHookTests.test_pull_request_synchronize
(imported from commit ef69467ed4a02dbfa94c8215fb9043b668d1dec9)
When folks closed issues or pull requests on github, we were
using the wrong field from the github payload. Now we
correctly use the "sender" as the person doing the action.
(imported from commit 82989ab19b32f8e3f0bbff9b305a7cb2673d99e9)
Added a default_desktop_notifications boolean to userprofile with a UI
in Zulip Labs. This flag is used to default the notification flag on new
subscriptions.
(imported from commit a25223cc5ecf09980cf877991e25034bb3fd4046)
If a user is not allowed to create new streams, then do not
show the "Create new stream" UI at the top of the settings page.
(imported from commit b97626938d8b612317c2189f7eca0d4bd27fc274)
Note that this doesn't actually restrict anybody yet, but it
makes it so that UserProfile.can_create_streams must return True
for a user to create a stream. We can modify that in the future
to have special behavior for realms that want more restrictions.
(imported from commit 432e85b1ca86aaee4a6bd1d4a6d0b2c78ecb0863)
Add back end for admins to assign/remove admin permissions for other users.
The /json/users/<email> endpoint allows you to PATCH is_admin.
(imported from commit bb5e6d44d759274cc2a7cb27e479ae96b2f271b5)
Previously we only disabled it for 'is:starred'. This caused a backtrace when
someone searched for, say 'stream:test is:mentioned', because we weren't joining
on zerver_usermessage, which meant the flag wasn't available to filter on.
(imported from commit ba19f8a74b21d60b89dfc8dbe9c8458ed86b423b)
Zendesk works a lot like desk.com, it has triggers which use targets.
The triggers have a user defined template. Targets can also have place
holders that are posted, we add the ticket id and title here so we can
always construct the message subject.
(imported from commit 04e8e5c7c0fc5568201f252546f6ed42f282fd00)
The normal code will now generate SQL that is basically identically to the raw
SQL we were using before.
(imported from commit 84a3971d6137d05ef3f71252278afdd59041e86a)
This commit also includes a few changes in the way we do some queries that
should speed searches up:
* Messages before and after the anchor are fetched in a single query by doing a
UNION ALL on the server. This incurs the cost of an extra sort because UNION
ALL does not guarantee the order that the results are appended, but it saves a
server round-trip.
* Searches involving flags now use a straight froward WHERE clause, which is
much faster than the one that django-bitfield generates (due to limitations of
the Django ORM)
(imported from commit a0db811a9073363cfabcf4b035d02d20dc8fc8a4)
This requires the tsearch_extras Postgres extension. To install the extension,
first install postgresql-9.1-tsearch-extras on both postgres-primary and
postgres-secondary (this would normally be done in a puppet apply, but there are
currently some changes that can't be applied on Postgres machines). Then run
the following as the postgres user on postgres-primary:
$ psql -d zulip -c 'CREATE EXTENSION tsearch_extras SCHEMA zulip;'
In dev environments, you must also run:
$ psql -d zulip_test_template -c 'CREATE EXTENSION tsearch_extras SCHEMA zulip;'
(imported from commit ad0a57c455b3b86002191ac5fb705d8f716f3296)
This is used by the Android app to authenticate without prompting for a
password.
To do so, we implement a custom authentication backend that validates
the ID token provided by Google and then tries to see if we have a
corresponding UserProfile on file for them.
If the attestation is valid but the user is unregistered, we return that
fact by modifying a dictionary passed in as a parameter. We then return
the appropriate error message via the API.
This commit adds a dependency on the "googleapi" module. On Debian-based
systems with the Zulip APT repository:
sudo apt-get install python-googleapi
For OS X and other platforms:
pip install googleapi
(imported from commit dbda4e657e5228f081c39af95f956bd32dd20139)
Previously we unconditionally showed the "get the desktop app"
banner. Now, if the first user declines to invite people as part of
their onboarding workflow, show the invite banner instead.
(imported from commit f7892fef17c923154a700149b8f5be99e9c03fa0)
We currently only do bulk invites when the first user in the realm
goes through the signup process, so this will help us know if that
step is effective for getting more early users into the app.
(imported from commit c846086185ed28b13d3d4b695a9c8cad913d3bc9)
Before this is deployed to prod, we need to manually frob our database
to set the is_mirror_dummy=True bit for all existing mirror users.
(imported from commit 39f1938cef091cf1d7d97307f76b137fe1d92b6c)
NarrowBuilder.by_stream and NarrowBuilder.by_topic for mit users uses a
regex to search by stream and topic. Python's re.escape escapes unicode
in a format that postgres can not parse. We escape unicode as '\uXXXX'
for postgres.
(imported from commit d2c27d4514c31fdc6ef1fea898fe721a6f0ab069)
After deploying to both staging and prod, double check the docs
are correct here. This fixes the API docs on prod, which had
"POST /api/v1/messages", despite "/api" not being part of the
prod path. Prod docs are here:
https://zulip.com/api/endpoints/
(imported from commit a2c4d316128f88171f4a76074314be64d9bc9728)
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)
Luke Faraone
Tim Abbott
Zev Benjamin
Tim Abbott
acrefoot
Steve Howell
Jason Michalski
Jessica McKellar
Leo Franchi
Kevin Mehall