GitLab

- Explicit handling of invalid email change activation code.
- Permission denied response if user is authenticated and email change code
  is assigned to another user.
- Improve logging
- Updated tests

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

Replace all AstakosCallpoint references

Refs: #3340

- Allow admin to overwrite default resources presentation data using
  ASTAKOS_RESROUCES_META setting. dict_merge is used to accomodate admin
  from declaring all available metadata parameters.
- Enforce allow_in_projects resource policy in project application
  form.

Assume a resource `astakos.pending_app' related to service `astakos'.
On submitting an application, issue a commission that will update the
related counter if possible, and accept the commission on success.
On approving/denying/cancelling an application, update the counter
likewise.

We always charge the application `owner'; however, if the `applicant'
is a project admin, we issue commission in force mode which succeeds
even if it exceeds the limit.

In order to pre-emptively check in the UI, follow the same process in
`dry run' mode, which issues a commission and rejects it on success.

Remove option of user-update to set its limit.

Refs #3349

All calls take a request_user (of type AstakosUser) argument.

Update view to use the introduced astakos quotas api.

- Remove presentation information from Service model (order, icon)
- To access the list of services filled with both presentation and api
  data use Service.catalog(). The method fills a dict with service
  identifiers and service metadata through the following steps
    - Initialize a service dict using
      astakos.im.presentation.service_defaults
    - Extend (merge and overwrite) it with the correspoding entry in
      astakos.im.presentation.SERVICES if exists.
    - Merge once again if user has set service metadata in
      ASTAKOS_SERVICE_META setting. This way user can change only the
      desired service parameters.

- An example of ASTAKOS_SERVICE_META containing keys which

    ASTAKOS_SERVICE_META = {
        'myservice': {
            'name': 'service_identifier',
            'url': 'https://service.url/service/ui/',
            'verbose_name': 'My service name',
            'order': 1,

            # cloudbar specific parameters
            'cloudbar': {
                'show': True,
                'title': 'My service name in cloudbar'
                # defaults to verbose_name
            },

            # dashboard specific parameters
            'dashboard': {
                'show': True,
                # we use different ordering in dashboard
                'order': 100,
                'description': 'My service description'
            }
        }
    }

- Updated dashboard to use Service.catalog() instead of hardcoded
  html.
- Updated service-* commands to keep up with model changes

- Remove foreign key dependency between Service/Resource model. Replace
  it with a service CharField to keep track of the service identifier
  that the resource was registered from.
- Remove all references to resource service name in resource lookups

UI-related presentation data go to presentation.py.
Remove load_service_resources call and related astakos-init
management command.

This is done for reasons of uniformity.

Replace custom transaction context with:

- decorator `commit_on_success_strict', which uses
  transaction.commit_manually and ensures that
  the transaction rolls back on any exception

- context ExceptionHandler, which logs and
  suppresses exceptions

Invite view and function had the same name.

Also deny GET requests for those actions

if not set, None is passed

# Fix send change email error message
# Remove double logging

Removing unnecessary code ( branding tags). Generic overview page.

We used to check the limit on applicant; however we would like to
to control pending applications per the original applicant, i.e the
owner. The check is ignored when the applicant is a project admin.

do not allow users that have not been moderated to activate themselves
using activation url

Major authentication provider refactoring to support

- Modular and easily configurable messages with common context
- Fine grained provider policies to support appling specific policies to
  users and/or groups

Key points:

- Use auth_providers.AuthProvider instances where auth provider logic is
  needed. Instances get properly initialized with the available context
  (with no user/signup view, with user/login view, with user and
  identifier/profile view).

- All authentication provider messages are now accessed using the
  get_*_msg AuthProvider attributes.

- Provider policies logic is handled from  get_*_policy attributes.

- All provider messages may be overridden globally or per provider level from
  settings::

  # global change
  ASTAKOS_AUTH_PROVIDER_NOT_ACTIVE = 'Provider not active'

  # change only applies to shibboleth provider
  ASTAKOS_AUTH_PROVIDER_SHIBBOLETH_NOT_ACTIVE = 'Shibboleth is not  active'

- Provider policies may be overridden in settings::

  # ALL users wont be able to add shibboleth login method from their
  # profile
  AUTH_PROVIDER_SHIBBOLETH_ADD_POLICY = False

- New provider policies profile model added. Profiles can be assigned to
  a group or/and a specific user.

- All tests updated to match the auth providers changes.

- New management commands included

  * user-auth-policy-{add, list, remove, set, show}
    Manage authentication provider policy profiles.

  * user-group-{add, list}
    User group management commands

- Updated user-list to optionally display auth provider information

Add logging statements on some important auth providers operations.

Complete auth providers logging support will be merged from the
feature-astakos-authpolicies branch which also includes additional auth
providers improvements.

Additional check to avoid verified inactive users reactivation

- Include uuid in email
- Response redirect after on successful form submission

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.

astakos allows users to replace pending created accounts (user that
have not yet passed the activation process) by re-submiting the signup
form. A message is now displayed in such cases to remind the user of the
pending account.

Override logout message for shibboleth auth provider. Suggest user to close all
browser windows until we find a better way to logout from Shibbolet.

At the project application detail, project administrators
(ASTAKOS_PROJECT_ADMINS setting) may approve or deny it.
A denied application is still viewable by the applicant,
until he dismisses it from the same page.

The project administrators' project list includes all projects.

If members have been successfully added