GitLab

- fix url conflict for .zip archive download
- fix empty zip file

close #268

I updated the tag views by importing the `Tag` model provided by the
Taggit plugin, deleted the `WebappTag` model and `TagForm` form that are
obsolete.
I updated the `WebappUpdate` view to follow the recommendation given by
the Taggit plugin documentation. The `TagList` now uses directly the
`Tag` model and send both the tag fields and a count of each tag
occurence.
I removed the `TagAdd` list that is obsolete. I updated the
`TagWebappList` that returns simply a list of all `Webapp`objects for a
given tag.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

Follwoing the merge, several bugs appeared. I added the import of the
`transaction` Django library and `get_base_url` missing function calls.
I updated as well the sandbox panel handle in the template because it
changed with the merge.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

This way we get redis updates when a job is deleted and this also
prevents inserting a 'DONE' state when the job is not done

Note: we never update the redis job state key from the django server to
avoid race conditions

This updates the job_list page in real time when the state of any
displayed job changes:
- update the status icon
- show/hide the abort button
- enable/disable the delete button
- remove job from the list when destroyed

(also changed the status_icon to fa-hand-paper which looks
 (i think ;-) less confusing)

close #222

(from the user point of view, these jobs no longer exist)

The controller and django can both change the job state, especially when
it is in the WAITING state (django may delete the job and the controller
may start the job).

To prevent any inconsistency, we must ensure that these transitions are
made atomically.

(because the controller must free the allocated resources first)

(chromium does support empty "Location:" header)

- form reformatted as a grid (using class form-row)
- when replacing a version
  - select the version used for starting the current sandbox
  - initialise the "changelog" field with the previous changelog
    of the version being replaced
- when creating a new version
  - initialise the "changelog" field with an empty value
  - raise an error if the entered version already exists
    (prevents accidental overwriting by the user)
- report commit result in a flash message

BERJON Matthieu authored Jul 25, 2018 and BAIRE Anthony committed Aug 01, 2018

The redirection for a successful webapp creation was wrong and created
an error. I fixed it by giving te right handle (i.e
`webapp_sandox_panel`).
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

- all sandbox actions a made from the same endpoint, so i renamed it as
  WebappSandboxPanel. It is an endpoint that accept GET and POST methods
- GET is rendered using TemplateView (nothing magic)
- POST is has an ad-hoc implementation that handles sandbox
  actions (start, commit, rollback, retry, abort)
- all POST actions are followed with an HTTP redirect (to make a GET)
  so that actions are repeated if the user refresh his browser window
- I changed the initial status of newly created webapps to IDLE because
  power users who upload their docker image do not need to start a
  sandbox

It is not finished, there are many FIXMEs/TODOs but it is working.

instead of '1' (which will mostlay always be wrong)

This is to avoid code duplication (the kind of nasty duplication
where is damn easy to forget to update both sides). Plus the converter
ensures the arguments are properly shell-escaped using shlex.quote().

This also fixes the resolution of the port when it is provided in the
X-Forwarded-Host header.

It is a good practice to authenticate before, because this prevents
leaking information.

(also i removed the json error messages because they are ignored by
 nginx, if we want to tune them, then we should do it in the nginx
 configuration)

(must return 401 instead)

I fixed the bug in two `DeleteView` views. The `SuccessMessageMixin`
doesn't work with `DeleteView` views because it's hooked to the
`form_valid` method which doesn't exist in this particular view.

I took the opportunity to rewrite the other success or error messages in
the other views in order to have something a bit clearer and easier to
read.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

I forgot the call of the `WebappTag` model into the view.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

I updated the form and view in order to take into account the tags.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

I added a route that let the logged in user to add a tag to the database
along with its controller and template. This patch is working but has
two flaws. The first is that the user is redirected to the home page and
it doesn't save the corresponding tag to the user's app.
It should do the latter and then redirect the user to the webapp update
template.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

Also we should return 401 if the user is unauthenticated and 403 if he is authenticated but not allowed to access the file.

authorization is done by django route /auth if user is logged or by token

This way all controller notifications will be implemented in a single
place and the notifications will also be sent when updating the models
through the /admin UI.