GitLab

Allow project enrollment and ownership only for users that are accepted,
not just email_verified.

Also change base quota only for accepted users.

Provide auth.make_user() as the single way to create a new user. This
function is responsible to set all automatically generated fields, such as
username, uuid, and token. Clean up AstakosUser.save(), that used to
update these fields, and remove AstakosUser.__init__(). Remove trigger
that renewed token on every AstakosUser update. In order to set a user's
email, use AstakosUser.set_email(); this takes care to update the
username, too.

Provide function create_user() in user creation forms, which calls
auth.make_user() with the form-provided data.

Use the wrapper auth.make_local_user() in management command `user-add'.

Use the same infrastructure to extend a django superuser to an AstakosUser
(in management command `fix-superusers').

InvitedLocalUserCreationForm, InvitedThirdPartyUserCreationForm,
ShibbolethUserCreationForm, and InvitedShibbolethUserCreationForm
were not used.

When new terms are added, set has_signed_terms=False for all users, forcing
them to accept the new terms. If there are no terms, a new user is created
with has_signed_terms=True.

With this change we can skip querying the terms when authenticating a user,
speeding up POST /tokens.

Rename flag `allow_in_projects' to `ui_visible'. Add flag `api_visible'.
The former entails the latter.

In python 2 we cannot have keyword-only arguments (PEP 3102).
And even if we could, this was not the right way to
declare a python function.

From Django documentation:
"""
It’s also important that you pass through the arguments that can be
passed to the model method – that’s what the *args, **kwargs bit does.
Django will, from time to time, extend the capabilities of built-in
model methods, adding new arguments. If you use *args, **kwargs in your
method definitions, you are guaranteed that your code will automatically
support those arguments when they are added.
"""

Replace IOError and PermissionDenied with project-specific exceptions.

Submit a project modification by specifying a project id rather than
an application

view always passes request argument. Avoid propagating it to ModelForm
constructor.

when recpatcha is enabled in astakos settings

- Direct access to user uuid is no longer useful to the users.
- `auth token`, `auth token expires` and `renew token action` are now accessed
  from the api access view.

Email subjects are parameterized by site name and application-
specific data. Other than that they should be constants rather
than settings.

Remove unused GROUP_CREATION_SUBJECT.

Import astakos settings module instead of importing specific settings

Use synnefo_branding.util.render_to_string accross synnefo apps to be able to
use branding variables within the templates.

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

Available join and leave policies are internally defined and should
not be changed by settings. Move policy descriptions to presentation.py.

Do not convert to string the lookup key in templatetags/filters.py

Implement 'join_urls' method for joining a base URL with a path,
without worrying about redundant or missing "/". Do not use
'urlparse.urljoin', since it has different semantics.

Form passes only a tuple (name, limit) for each selected resource,
omitting presentational data.

- 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.

- 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.

- Use project setting SERVER_EMAIL as sender to all email notifications.
- Remove astakos specific DEFAULT_CONTAC_EMAIL in favor of snf-common's
  CONTACT_EMAIL setting.
- Remove DEFAULT_CONTACT_EMAIL and ADMINS astakos specific settings in favor of
  common ADMINS/MANAGERS/HELPDESK email lists which are now provided by the
  snf-common package. The settings are used as follows:

    * Project created notification: MANAGERS + HELPDESK
    * Account created (moderation pending): MANAGERS + HELPDESK
    * Account activated: MANAGERS + HELPDESK
    * Feedback: HELPDESK

An admin can modify a project, i.e. create an application based on
a previous application. We distinguish the initial applicant, called
the `owner', from the user who submitted the current application,
called the `applicant'.

Show owner instead of applicant in project-list: the applicant can
vary among applications for a single project, but owner is likely
to be unique.

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