Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Terms of Service: Add ability to update TOS and have users re-sign. #1597

Closed
wants to merge 2 commits into from

Conversation

rishig
Copy link
Member

@rishig rishig commented Aug 10, 2016

Most directly useful for the migration to zulipchat.com.

Creates a new field in UserProfile to store the tos_version, as well as a
special MIGRATION_TOS_VERSION that triggers slightly different text on
accounts_accept_terms.html. We check for a version mismatch between what the
user has signed and the current settings.TOS_VERSION whenever the user hits
the home page, and redirect them if needed.

Note that accounts_accept_terms.html and zerver.views.accounts_accept_terms
were unused before this commit (I'm guessing they are from the Dropbox
migration in 2014.)

@smarx
Copy link

smarx commented Aug 10, 2016

Automated message from Dropbox CLA bot

@rishig, it looks like you've already signed the Dropbox CLA. Thanks!

settings.EMAIL_HOST_USER,
["all@zulip.com"])
do_change_full_name(request.user, full_name)
do_change_tos_version(request.user, settings.TOS_VERSION)
Copy link
Sponsor Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

probably this piece should be conditional?

@rishig
Copy link
Member Author

rishig commented Aug 12, 2016

updated

@timabbott
Copy link
Sponsor Member

Cool, looks pretty good. I realized that we can also remove templates/zerver/tos_accept_body.txt, so I added code to do that; will merge once the build with that tweak passes.

@timabbott
Copy link
Sponsor Member

Oh, also, I updated the default for UserProfile.tos_version to be settings.TOS_VERSION; I think that's correct, since any new users created will have signed whatever the current TOS is. Let me know if you see any issues with that!

@rishig
Copy link
Member Author

rishig commented Aug 12, 2016

The UserProfile.tos_version gets set in the registration flow -- seems like starting at null and then getting changed is more natural, to maintain the invariant that the field always reflects what the user has agreed to?

@timabbott
Copy link
Sponsor Member

Well, there are a few scenarios:

  • A totally new user. That user signs the current ToS as part of signup and should be get the default value of settings.TOS_VERISON
  • A migrated user. That user will be imported from another server, and thus if settings.TOS_VERSION differ between the two servers, they will be asked to sign. The plan is to have the pre-migration server have settings.TOS_VERSION=None and the new server have settings.TOS_VERSION=1.0, which I think creates correct behavior.
  • An existing user where the server has changed its TOS_VERSION. Then, their user_profile.tos_version != settings.TOS_VERSION (since the latter changed), and they will be prompted to accept the ToS.

So I think my proposed logic is correct -- right?

email = request.user.email
domain = resolve_email_to_domain(email)
special_message_template = None
if request.user.tos_version is None and hasattr(settings, 'FIRST_TIME_TOS_TEMPLATE'):
Copy link
Sponsor Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This hasattr line is incorrect. You want settings.FIRST_TIME_TOS_TEMPLATE is not None, since we're set a default value of None for this settings in zproject/settings.py.

A design goal of our settings system is to never need to do a hasattr check for a setting -- we always set a default, so you're always guaranteed you can access it (and check for None if appropriate).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah cool, makes sense.

@timabbott
Copy link
Sponsor Member

https://github.com/timabbott/zulip/tree/terms-candidate is my version having squashed the fixes above into your commit, in case the reference is useful for review.

@rishig
Copy link
Member Author

rishig commented Aug 12, 2016

oops, edited my comment as you were writing yours. The logic is correct, though it was more natural for me to think of it as

  • UserProfile.tos_settings always has what the user has currently agreed to.
  • Whenever the user signs something, UserProfile.tos_settings gets set to what they signed.

This way it's clear what happens if e.g. the user gets partway through the registration flow, or if the user is created by some future batch process that avoids the registration flow, etc.

@timabbott
Copy link
Sponsor Member

Cool, yeah, I think that's actually what my model does; a few notes:

  • UserProfile.tos_settings is only initially populated when the user creates their account (and thus signs the ToS)
  • There's a separate table, PreregistrationUser, for users who haven't finished the registration flow, so that side is OK, though we do have a special case of is_mirror_dummy users that we should take a look at (we might need to set user_profile.tos_version = settings.TOS_VERSION in the code path for turning one of those into a real user).
  • We don't really support batch operations to create users without the registration flow. Though, I guess we do have a create_user API. Hmm, let's look at that in the morning. That actually might be a flow through which the old codepath might have been used ...

@timabbott
Copy link
Sponsor Member

I went ahead and merged this, but we should still into those follow-up details.

  • For do_activate_user, I think that should set user_profile.tos_settings = settings.TOS_SETTINGS. That function is only used on the "activate a mirror dummy into a real account" code path, and the mirror dummy basically will have some random past value for user_profile.tos_settings set.
  • create_user_backend in zerver/views/users.py is the API endpoint for creating new users (we used for e.g. bulk-creating user accounts in advance of the people showing up for Mystery Hunt, for example). It should probably set user_profile.tos_version somehow, so that those users get prompted to accept the ToS when they first login.

@rishig
Copy link
Member Author

rishig commented Aug 13, 2016

still working on TOS flow, but reordered commits so privacy policy is first

Mostly just changes "Zulip Account" to "Kandra Labs Zulip Account" or
"Account", changes "Zulip" to "Kandra Labs", and changes "Massachusetts" to
"California".
Most directly useful for the migration to zulipchat.com.

Creates a new field in UserProfile to store the tos_version, as well as two
new settings TOS_VERSION and FIRST_TIME_TOS_TEMPLATE. We check for a version
mismatch between what the user has signed and the current
settings.TOS_VERSION whenever the user hits the home page, and redirect them
if needed.

Note that accounts_accept_terms.html and zerver.views.accounts_accept_terms
were unused before this commit (I'm guessing they are from the Dropbox
migration in 2014.)
@timabbott
Copy link
Sponsor Member

Merged.

@timabbott timabbott closed this Aug 13, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants