GitLab

set accepted_policy to 'migration' for already accepted users which have not yet
a verified email address (old flow)

Major refactoring on user email verification/activation process
---------------------------------------------------------------
Activation logic moved from dispersed code in functions/view modules to
ActivationBackend methods. All user activation handling code in astakos views
and command line utilities was updated to use activation backend instances.

User moderation takes place right after user has verified the email address used
during the signup process. This solves issues caused when users signed up using
an existing but not yet verified email, causing invalidation of previously
moderated accounts.

A bunch of new fields added in AstakosUser model. Those fields added to clear up
a bit the identification of user status at a given time and additionaly keep
track of when specific user actions took place as a reference for
administrators. The following section contains detailed description of each
introduced field.

Introduced AstakosUser fields
-----------------------------

Fields get properly set across sigup/activation/moderation processes.

* verification_code
  Unique identifier used instead of user auth token in user email
  verification url. This is initially set when user signup and gets updated
  each time a new verification mail is sent (requested either by admin or user)

* verified_at
  The date user email got verified.

* moderated
  Whether or not the used passed through moderation process.

* moderated_at
  The date user got moderated.

* moderated_data
  A snapshot of user instance by the time of moderation (in json format).

* accepted_policy
  A string to identify if user was automatically moderated/accepted.

* accepted_email
  The email used during user activation.

* deactivated_reason
  Reason user got deactivated, provided by the administrator.

* deactivated_at
  Date user got deactivated.

* activated_at
  Date user got activated.

* is_rejected
  Whether or not account was rejected.

South data migration included.
******************************

Handles user entries as follows

Users with no activation_sent date
----------------------------------
- Generate and fill verification_code field.
- Once user will visit the activation url an additional moderation step
  will be required to activate the user.

Users with verified email which are not active
----------------------------------------------
- Set moderated to True
- Set is_active to False
- Set moderated_at to user.auth_token_created
- Set accepted_email to user.email
- Set accepted_policy to 'migration'
- Set deactivated_reason to "migration"
- Set deactivated_at to user.updated

Users with verified email which are active
------------------------------------------
- Set moderated to True
- Set moderated_at to user.auth_token_created
- Set accepted_policy to 'migration'
- Set accepted_email to user.email
- Set verified_at to user.moderated_at

Users with no verified email and activation_sent set
----------------------------------------------------
- Set moderated to True
- Set moderated_at to user.updated
- Set verification_code to user.auth_token (to avoid invalidating old
  activation urls)

Updated management commands
***************************
- New options --pending-moderation, --pending-verification added in `user-list`
  command.
- New fields verified/moderated included in `user-list` command.
- New moderation options `--accept`/`--reject` added in `user-modify` command.
  `--reject` can optionally be combined with `--reject-reason`.

Other changes
*************
- Cleaned up explicit smtp error handling when sending email notifications.
- Prevent already signed in users from using an account activation url
- Allow user to logout even when latest terms where not accepted
- Renamed templates
    * helpdesk_notification.txt -> account_activated_notification.txt
    * account_creation_notification.txt ->
        account_pending_moderation_notification.txt
- Updated im tests

Add attribute `allow_in_projects' in Resource model (True by default).
Set this flag for astakos.pending_app to False in the description
of astakos resources.

- Rename 'pithos+' to 'pithos'
- Prepend resource names with 'service_name.'

Rename it to fields.py and update all migrations that reference the field.

Add field `response' in ProjectApplication model.
Add option `-m' in project-control command.

Refs #3493

Add UserSettings model for storing integer-valued settings.
If an entry is missing, a default synnefo setting is consulted.

The limit can be set/unset with snf-manage user-update.

Keep chain IDs in table Chain and add foreign keys from ProjectApplication
and Project to Chain.

This will allow us to reference a possibly not yet approved project
in a more concise way.

Add an 'uplimit' (default) field in Resource;
change AstakosUserQuota fields to IntDecimalField;
pass all four limits of initial quotas to the quotaholder;
register services and resources explicitly upon creation;
a wrapper for get_quota.

Change Project's state field and ProjectMembershipHistory's person field;
replace all migrations starting 0015 with a single new one.

Need to check for missing data migrations.

- Enrich login/logout messages.
- Clear unverified accounts when user adds the same third party account
  to an existing account.
- Other minor improvements.

Update Astakos API to provider calls for retrieving uuid from the username and vice versa, extend astakos client library (snf-common) and update pithos to use uuids instead of email for account identification

auto generated user identifier

- Store additional provider info in PendingThirdPartyUser entries
- Include third party registration logic in main signup view. Additional
  per provider signup views removed.
- Unique email validation for all activation backend forms
- Keep created dates in auth provider and pending user entries
- Other minor fixes

New menu

Refs: #2416

Register the date a user activation email sent and reset it when the user becomes active (for future use)

This field can have the following values:
* epoch:						signifies the user has been created before adding the specific field (so we have no actually information whether an activation email has been sent or not)  
* NULL:							signifies the user is active or no activation email has been sent
* other date (except epoch):	 the date the activation email sent

Passing the -n option in list users snf command shows only the new users (created after adding the field) who have not received an activation.

Refs: #2471

* new model Service
* new management commands for handling the services
* remove ASTAKOS_CLOUD_SERVICES setting
* change get_services API call to return
the Service objects
* separate admin from service API calls
* introduce send_feedback service API call

Refs: #2413

Refs: #2363