GitLab

Forbid enrolling an inactive user in a project or accepting their join
request. Also when setting a user inactive, suspend memberships for
terminated projects, too.

- Add unit tests for the `EmailChangeForm`
- Move all the logic from the EmailChange form into
  a `change_user_email` util.
- The form's `save` method now raises a
  `NotImplementedError` exception.
- Make the `request_change_email` view use the
  new `change_user_email` util.
- Make the `send_change_email` user util independent
  of the `HttpRequest` object.

Create the 'LDAPAuthProvider' to authenticate against an LDAP service.
This provider is making use of the 'django-auth-ldap' package. However,
the 'django_auth_ldap.backend.LDAPBackend' is make to work as a Django
authentication backend, and so to automatically creates a User object.
Because this does not match with how Astakos is handling authentication
of third party providers, we override the 'get_or_create_user' method to
create a mocked user object, which will be used by our provider to
create the final AstakosUser object.

Extended the 'AuthProvider' class with a dictionary, mapping provider's
attributes to AstakosUser attributes. Also, this dictionary dictates
whether the user can change an attribute, or the value of this attribute
is automatically set by the provider.

Also, update profile forms by making attributes that are forced by the
provider to be read-only.

Finally, if all attributes are forced by the provider the
'ThirdPartyCreation' form is not required. In this case, the user is
 the AstakosUser is automatically created with the profile that is
 provided by the provider.

ASTAKOS_SITENAME is deprecated in favor of BRANDING_SERVICE_NAME

- Always send limit on members number back to project modification api
  call (modified to unlimited otherwise)
- Validate that total limit is always equal or lower than members
  resource limit.

Do not import the transaction module from django.db. Import it instead
from astakos.im, where the Astakos transaction entry points are located.

the field description changed for field description clarity when
displayed in user management commands context resulting confusion when
appeared in terms acceptance form. Fixed by reverting field label in the
terms acceptance form class.

- Use combined form widget with proposed max members values and
  custom input in project create/modify views form.
- Improved handling of infinite resource values.
- Display project overlimit bar in usage view.
- Automatically fill `per member` resource quota if not set.
- Display all projects in usage view. Option for `sytem only`
  display removed.

Split `im/functions.py` in two parts. Rename the first part as
`user_utils.py` and keep in it all user-related utilities that
`im/functions.py` provided (mainly mail utilities). The second part is
the project-related functions, which will be kept in `im/functions.py`
for now.

Also, fix any broken imports that this split introduces.

Change the name of projects from "base:UUID" to "system:UUID", so as
to avoid confusion, since the name is visible in management commands.

- Fix applicant permissions in project detail view.
- Restrict project owner email to be visible only by project admins.
- Fix access to unitialized project detail view.
- Alternative realname display for base projects.
- Do not require total members number in projects form. Set to infinite if
  no value is set to mimic api behaviour.
- Use application.owner instead of project.owner in the project listing view.
- Revert optional base project visibility in admin project list view.
- Display error when user is not allowed to call project action.
- Fix ordering of per member/total resources display.
- Remove "cancel" action in create/modify project summary view.
- Differentiate project modification heading (append "modification" suffix).
- Reword "base project" to "system project". "[system]" prefix with
  user email address and name is used to display base projects to admins.
- Hide details/membership sections in base project modificatation/details views.

- Include total quota help text for each resource.
- Two column layout for per user/total quota.
- Fixed owner formatters in template filters.
- Proper display of unset project application resources.
- Hide base projects by default. Include base project toggling action in
  projects list view.
- Set proper project name field validators for base project in
  project modifcation form.
- Improve visual highlighting of quota diffs
- Improve membership status messages
- Improved project filtering in project list/join views
- List all public/active projects in `join project` view.
- Handle unowned projects in projects modification form
- Display all project resources in project application summary view.
- Permit zero values in project application/modification form.
- Avoid modifcation of immutable base project fields in project modification
  view.
- Display project/application creation date to project admins.
- Remove user base project when a user gets removed.
- Convert ProjectForbidden exception to 403 http responses.
- Additional user access checks handling in project/app detail view.
- Let both applicant and project admins to dismiss a denied project
  application.
- Forbid project owner to act upon an admin project modification.
- Prevent POST requests in project modification detail view.
- Handle pending app quota per applicant
  When applying for a modification, the existing pending modifications,
  which will be replaced, may have been initiated by another user. We need
  thus to handle the astakos.pending_app resource per applicant.
- Introduce `related`, `active` mode in projects list api call
  Related mode returns all projects user owns or is has a related
  membership to. Active mode returns available public/active projects.

According to the decision of the GRNET Board of Directors,
switch license to GPLv3.

This commit will be propagated to the release
and master branches based on git flow, and the next
release will be licensed as GPLv3.

- Fine grained handling of project modification field (exclude unchanged fields)
- Display modified fields in project modification details/summary views
- Set distinguished content in project/app details/summary views
- Minor styling improvements

Update Copyright for files merged into develop in 2014 concerning the new
projects mechanism.

- Update project views to work with the updated projects logic
- Use api.projects methods when applicable
- Common project view decorator
- Common view for app/project details

Custom EmailValidator class backported from django 1.6

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.