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>

I updated the view and template in order to be able to regenerate a
token if the user needs to do so.

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

I added an attribute to the form to make him read only. Now just the
"generate" button needs to be handled properly and find a way to display
the value of they token key into the field.

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

I Updated the user form view and created two new views for the ssh key
and token. The current token view doesn't work properly and needs to be
handled in a better way. It shouldn't be a proper form anyway, just a
button to generate a new token if necessary.

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

I added the creation of a token at the user creation.

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

I added the authentication using basic tokens that corresponds to the
current API.

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

I updated the API in order to manage jobs.
Now the GET and POST http commands are available to select and create
jobs for a given user (on `jobs/` endpoint).
The GET and DELETE http commands are available to select a given job for
a given user on `jobs/<id>` endpoint.

I updated the `settings.py` file I added two variables to have
informations related to the datastore directory and the directory name
that will host the jobs files. The current setup is
`/vol/rw/datastore/jobs/<job_id>`.

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