GitLab

for two reasons:
- it is no longer a concern since email addresses are well verified now
- it was broken (an entry would be created in auth_user anyway,
  whereas the other tables would not be updated)
- it was doubly broken (raise PermissionError on first gitlab login too)

this had the bad effect of making all links/buttons disapper
when clicked

(now that allgo supports multiple e-mail addresses per user, they
 can resolve the problem without the admins)

because the decimal format is kind of messy, especially we have:
1.01 != 1.1 and 1.1 == 1.10

Tos.version is now a CharField. For ordering, we use Tos.id instead
(the latest tos is the one with highest id).

- remove the HasSignedTosMixin and to the verifications in
  AllgoAccessMixin instead (along with email verification)
- add Tos.get_latest() and User.has_agreed_tos
- ignore ToS agreement if the db has no ToS entries

(this is a legal document, we should avoid juggling with multiple
 variants)

BERJON Matthieu authored Nov 07, 2018 and BAIRE Anthony committed Dec 06, 2018

I added a mixin that checks if the user has accepted the latest ToS
version. If not the user is redirected to the ToS validation view. Once
accepted the user is redirected to the page he asked first.

I updated all the `login required` views by adding this new mixin.
One major issue of this code that the redirection argument passed to the
ToS validation view is the url name which is not a good practice I
think. A better case would to use the path but I wasn't able to write
the right regex in the url dispatcher.

Another issue is that the user won't be redirected at login or sign up
to the ToS validation view. This should be handled in the `adapter.py`
file.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

BERJON Matthieu authored Nov 07, 2018 and BAIRE Anthony committed Dec 06, 2018

I added a view to display the latest version of the ToS. This include a
specific url, its related view and template. I edited the footer as well
to add a link to the ToS.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

BERJON Matthieu authored Nov 07, 2018 and BAIRE Anthony committed Dec 06, 2018

I added two models for ToS system. A first model called `Tos` that
stores the data itself of the policy using a version number and a link
to a PDF version if necessary. The content of the policy should be
written in markdown.
Another model just stores the user and its related ToS version in order
for the user to be able to sign several versions.

I updated the admin to display the information related to the ToS
models.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

(and use the /accounts/email/ page (provided by allauth) instead)

'User.email' should never be updated directly

The rationale is that we rely on allauth for verifying e-mail addresses.
Allauth manages user's email addresses independently (one to many), and
updates User.email when one of these addresses is promoted to the
'primary' status. We will have less friction if we embrace the allauth
way of managing e-mails.

The good point is that allauth will never mark as primary an email
addresse that has not been verified.

There are multiple reasons:
- we can use the same page for validating the 'Terms of Use'
- the user may already have received the message
- we should do the same validation on the API too (but API should not
  send any email but just display the error message)

email.addresses lists all email addresses belonging to the user
thus we can make more generic queries

also adds EmailAddress.is_provider

remove the IsProviderMixin and introduce 3 new mixins:
- UserAccessMixin     -> must be a registered user
- ProviderAccessMixin -> user must be a provider
- AllAccessMixin      -> may or may not be a registered user

All these 3 mixins will also ensure that the user email is validated.

The purpose of the AllAccessMixin is to force the validation of the
email when the user is registered, thus the validation will be
requested when landing on the webapp_detail page rather than when
submitting the first job (which would be discarded)

and force displaying the card if it contain any invalid field

(thus user does not get confused if submit fails because of an invalid
 value in the non-displayed tab)

(this is to avoid discarding changes in the form if the user follows
one of these links)

I created a favicon and added it to the base template.

Resolves: #284

Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

webapp lists should never display apps not visible by the request.user
(obviously!)

TagWebappList did not implement such a filter. I added the
query_webapps_for_user() helper and use it for TagWebappList, TagList
and WebappList (the list returned by this function is the superset of
webapps that these views are allowed to display).

The URL in the breadcrumb was calling the app `name` instead of the
`docker_name` creating errors when an app was using several words in it
and therefore not corresponding to the `docker_name` anymore. This is
now fixed.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

The tags aren't mandatory at the creation as noted by @abaire

. I added
the argument `required=False` in order to correct it.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

As noticed by @abaire

, the title wasn't updating accordingly to the
endpoint type. This is now fixed.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

(for convenience)

Checking user.email is not ok because allauth allows multiple
addresses per user but grants access if any of them is verified.

-> we need to ensure that the matched address is verified


Thus a (non-admin) user can import a webapp only if the two
conditions are met:
- the user is allowed to create webapps (verified by IsProviderMixin)
- the user has a verified email address that matches the owner
  address of the imported webapp

Allauth supports multiple email addresses per user. While this is
not intended in allgo, it is still possible to configure multiple
addresses using the /accounts/email/ endpoint.

Problem: even with ACCOUNT_EMAIL_VERIFICATION="mandatory", allauth
does not ensure that all addresses are verified. It only ensure
that *any* address is verified.

--> even if the user is validted by all auth, we still need to ensure
that the relevant address is verified before granting access

I added two forgottent links such as:

- Commit a new version
- Import a current version of an existing app

I integrated them into the tabs and are displayed only when an app is
updated (not for creation).
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

I updated the template to display the right submit button message if the
endpoint is about to create or update the webapp.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>