We now show a list of users and allow you to deactivate a user using the
same process as `python manage.py deactivate_user`.
We add a new menu item accessible from the gear icon which will eventually
have much more than just this, but we have a good start here.
Here we also add a property to UserProfile which determines whether you're
eligible to access the administration panel, and then have code which shows
the menu option if so.
This introduces a new JS file, admin.js.
(imported from commit 52296fdedb46b4f32d541df43022ffccfb277297)
Previously, we'd determine unread counts client-side as messages got
loaded, which meant:
a) how many unread messages you were known to have kept changing
b) you could bankrupt yourself and then get the bankruptcy message
again as more messages arrived from the server
(imported from commit 90f1af27b493c720f77d37487d8746749faf157e)
ALLOW_REGISTER was no longer being used in determining whether you could
register for the app, so I've removed it to avoid additional local-dev /
production issues.
This closes#1613.
(imported from commit c928c6d350602d35f745ae1e60d734e4567885fc)
We add a new validator that ensures that people who sign up with @mit.edu
addresses are in fact MIT users.
This closes#1612.
(imported from commit 1e30794b1615dd57cb0e367d1fa186a877253357)
This is an experiment to try to ease the customer3 onboarding process
given that there will be a website with a public feed of recent Zulip
messages, to ensure that those messages appear for new users.
(imported from commit 31fb59c1800728b5e4d8a5ce7282c7dcedb02b21)
This if statement stopped working when we made the pointer managed via
the events system.
(imported from commit 382ca5bd055ab85048b211068ff3d43a47607f28)
Our API documentation says that we do, and it seems like it could be
useful to clients, so we might as well do it.
(imported from commit c391e4952a09d41df4dc06e3dc6ee094f774822b)
The main changes are:
(1) Changing the input format for the example response so that it is
human-readable and editable
(2) Updating it to use the events API
(imported from commit 308fade9595d6877836d343d2307e3fceff3e7d4)
This fixes trac #1660. A deactivated user may still have the
active flag set to "true" on their subscriptions, but this is
just to help future reactivations; they are not actually
valid subscribers while deactivated, so we add UserProfile.is_active
to our filter in the query in get_subscribers_backend().
(imported from commit 8598b2e180faea618371293e42b794898e645004)
We need to be able to let a user through if they are trying to sign up
for a completely open realm like CUSTOMER3.
(imported from commit 1e33ab0ce94545f217739d501e9227dfb48e1123)
It will have new callers soon and that's as fine a place as any to
avoid circular imports.
(imported from commit 089a724e9ad06cb5a51ffe80f1729d789238e5f6)
This needs to be deployed to both staging and prod at the same
off-peak time (and the schema migration run).
At the time it is deployed, we need to make a few changes directly in
the database:
(1) UPDATE django_content_type set app_label='zerver' where app_label='zephyr';
(2) UPDATE south_migrationhistory set app_name='zerver' where app_name='zephyr';
(imported from commit eb3fd719571740189514ef0b884738cb30df1320)