In the django admin, the webapps were listed as WebappObject and
unreadable. I updated it in order to have a list type [id, name, owner].

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

I updated the pages of web detail and web app list for a given user to
change the title page and style it in a certain way. It gives
consistency accross the pages.

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

I removed the contact field and replace it by a owner field that is
based on the current username of the owner of the app.
If this field is changed, then the current user won't be able to access
the form anymore.

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

I tried to improve the public webapp list. It's far from perfect but the
menu on the right look a bit better. I changed as well the look of the
tags. Move the contact and update on the right of the app title.
I removed the margin between the title and description.

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

In order to add a link to a Jupyter notebook I had to perform several
changes.

The URL field provided by django is unable to manage git url type such
as `git@example.net:user/repo` therefore I changed to a CharField.

I updated the field validator for the field `notebook_gitrepo` and use a
generic regex. At the moment I ensure that the url corresponds to
`git@something`. It's a bit light but it's a start.

I added the jupyter hub link for an authentified user that is the owner
of the application in public webapp list.

I fixed as well a missing closing tag.

The placeholder attribute in the webapp update form on the
`notebook_gitrepo` form was wrong. I fixed it and updated the content in
order to specify the type of url expected.

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

I updated the django table list in order avoid raising erros and take
into account the runner.

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

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

A user can manage one app (several later). In order to be to do that I
created two views. One to list the apps belonging to him, another one to
edit a given app. Two routes have been created as well to perform these
actions. Two forms and templates have created as well and modified to
correspond to the current graphical chart. The user menu and the public
webapp listing have been updated to show the buttons to list or edit the
apps wherever it applies.

The model of `Webapp has been modified as well. A first modification was
about the `private` that was an integer. Because the value can be only
true or false, I changed it to a boolean. A field has been added called
`notebook_gitrepo` that corresponds to a URL to a git repo and used to
call the Jupyter hub and run the notebook.

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

I updated all templates dealing with forms in order to display any
possible error message in the parent template.

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

I added a block dedicated to the messages that can be overriden from any
child template.

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

I added a message when the form is submitted successfully.

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

In order to follow Sébastien's advice, the `AllgoUser` model take a
default value on the token rather than overriding the save method in
order to prevent any issues if a user is generated by bypassing the
django user model.

I changed the view in order to generate a new token each time the user
wants to do so using a HTML form. This change follows the token
generation modification in the model.

Because we don't use the rest_framework anymore, I removed the call
inside that form.

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

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

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

I updated the model name of the views.

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

I forgot to update the path to the SQL file to apply the migration after
the table creation.

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

The current process to migrate the data suffers from side effects,
especially when the database needs to drop, start from scratch and add
some migrations through Django. Django handles really badly an existing
database and it's impossible to reproduce a migration process from
scratch when django migrations had been add up to the current database
migration process.

This commit resolve this by reversing the process from migrating to old
database to the new one and telling django to take this new database as
it is to telling Django to create the database from his models and
then inserting the data into the new database. By doing so, any
migration applied through Django is taken into account at any stage
during the process.

During the rewriting of the migration process I discovered several
issues that needed to be addressed.

- deletion of the token management library
- add of a token field in the allgo user table
- add of foreignkeys instead of onetoone fiels in the webapp to avoid a
uniqueness issue on fields that were supposed to have several times the
same ID.
- Update of the default values of job's fields

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

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

The django site ID is used by third party applications to work properly.
It corresponds to the absolute URL of the website that differs in
production, qualification or development, therefore, I added it with its
default value for production.

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

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

Further cleaning & integration in the django container

See merge request !28

I forgot to update the path to the SQL file to apply the migration after
the table creation.

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

The current process to migrate the data suffers from side effects,
especially when the database needs to drop, start from scratch and add
some migrations through Django. Django handles really badly an existing
database and it's impossible to reproduce a migration process from
scratch when django migrations had been add up to the current database
migration process.

This commit resolve this by reversing the process from migrating to old
database to the new one and telling django to take this new database as
it is to telling Django to create the database from his models and
then inserting the data into the new database. By doing so, any
migration applied through Django is taken into account at any stage
during the process.

During the rewriting of the migration process I discovered several
issues that needed to be addressed.

- deletion of the token management library
- add of a token field in the allgo user table
- add of foreignkeys instead of onetoone fiels in the webapp to avoid a
uniqueness issue on fields that were supposed to have several times the
same ID.
- Update of the default values of job's fields

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