Two methods are provided to save a file attached to a document, save and save_file, both located in the upload.py file. They seem to do approximately the same thing, but the return value and the raised exception are not the same. Is it really useful to have these two methods, with such confusing names ? It would maybe be better to juste have one method to do this.

Similar to #50 and #51, not all archives should be accessible by every user.

In order to authenticate, the server verifies that the client sends a "bearer token", as defined in the OAuth2 protocol. The server expects a header field in the following form :

Authorization: <jwt>

However, the RFC 6750 recommends that the header should be in the form :

Authorization: Bearer <jwt>

In the current system, the field is missing the 'Bearer' part with a whitespace afterwards.

When making a POST request on the /document route, if the code 422 is returned (because, for example, the position is not a valid number), the file passed in the form data is still uploaded and stored in the 'upload' folder. In this case, the file should not be saved.

The document images uploaded by the client are stored in a folder named upload that must be created manually.

This folder should be automatically created in the code if it doesn't already exists when the first image is uploaded.

The route GET /document/:id can be accessed without an Authorization field (which mean without authentication). As this route allows to access documents that are have not been validated yet, it is a problem. Only the user who posted it or the administrators / moderators should be able to consult a submission.

The only users that have the right to delete a comment are the admins. A comment author have no right to delete its own comment.

Similar to #50, anyone can access files from documents that have not been validated yet. It shouldn't be possible for a user that isn't admin, moderator or the author to consult a submission's file.

The only optional field in the request POST /document is the link field, which specifies a file attached to the document. This field should be mandatory as what we call a document represents a file with extra information.

When deleting a document with the route DELETE /document/:id, the file associated with (in the upload folder) is not removed.

Currently two routes exist with the same name, '/guidedTour'. The first one is used to create a guidedTour but accepts any HTTP method, while the second is used to retrieve all tours and only accepts GET. When a client makes a request of this form : 'GET /guidedTour', this actually triggers the creation route as if it was a POST request. We must specify in the API that the route must only take POST requests.

The CityTiler sub-dir holds an original version of what has now become a sub-part of the py3dTilers.
Assert nothing (possibly valuable) is lost (despite the history) and

• remove that sub-dir
• expurge the repository landing page accordingly.

Both front-side and backend share the same licence.
UDV has one.
Make UDV-server symmetrical

The API is described in a wiki page, but it is not up to date. @laurenttainturier started to make a better version with Swagger, which we could either include or link in the wiki once it is finished.

As the method send_reponse (in api/web_api.py) is always used in the same way in route methods, it would be more convenient and would make the code more readable to use it in a decorator way. The function was designed as a decorator (taking an old_function and returning a new_function), it would need few to no changes in order to call it as a decorator.

In the config file of the container extend_doc_db, the current implementation chooses to automatically start it (line restart: always), which is in fact a good way to avoid several bugs using it.

However, that means that even if we do not need this container, it uses the 5432 port, then compels us to "free" this port by running a few commands (listed below) before being able to start a new container using it.

Especially when we want to work with the 3DCityDB container, we face this problem in a systematic way.

sudo docker container ls
sudo docker container stop extended_doc_db

Suggestion (cf. container documentation):

# Instead of this :
restart: always

# We could try this :
restart: unless-stopped

This separation between Document requests and GuidedTour requests can be done (at least) at two levels (if we admit they share the same DB):

• separated the routes
• separate the server/port

Aim for the stronger server/port separation and fold back to route separation if it hurts too much...

When this separation is effective move one step further and separate the repositories. These should be differents UD-Tools

API_Enhanced_city is an autonomous component that deserves its own repository and

• create a UD-multimedia_db repository
• create ANOTHER UD-multimedia_db-docker repository
• distribute API_Enhanced_city files to one of the above repos
• remove what was moved out of UD-SERV, because DRY)
• within UD-multimedia_db-docker` separate the context from the docker-compose example
• Open further issues in those repositories for what requires some fixes

Bring client-side together with server side.

The following should be an issue in the new repository. An implementation of client side (GUI/JS) usage of this component
is located in the UD-Viz component:

• Contribute
• DocumentComments
• DocumentValidation
• Authentication
• ...what concerns GuidedTour...

What about moving that code within this UD-multimedia_db repository, and make it a JS package, and import that package to UD-Viz.

The advantages would be:

• one can GUI explore (explore with a GUI) the component usage
• keep the client side-close to the server-side because they co-evolve
• avoid polluting UD-Viz with this component (as opposed to e.g. some other implementation)

Two routes are defined with the same route, '/guidedTour'. The first one is used to create a new Guided Tour and the second one is for retrieving them. However, the first route accepts any HTTP method, which means that the second one (which takes only the GET method) can never be called. This results in many errors such as 500 or 422 responses (when the fields for the creation of a guided tour are not provided), or the creation of unwanted guided tours.

Problem

The route used to create a guided tour (/guidedTour) takes 2 arguments : the name and the description of the tour. However, whereas each POST method in the API takes their arguments as form data in the body of the request (content type multipart/form-data), /guidedTour takes them as URL parameters (coming as fields after the ? in URL).

Examples

Actual request

Expected request

Dates attributes (like publicationDate, or refDate in ExtendedDocument) are currently stored as a String instead of an appropriate type. As SQLAlchemy provides types such as DateTime, it would be better to use it.

When a comment is posted, the date at which it was submitted is not stored in the database. They should have at least one date field in order, for instance, to display them in the right order.

In order to work, the document creation route call the database twice. First, it creates the document and retrieve the id. It uses this id to save the file associated with this document. Then, it updates the document in the database with the path to the saved file.

These operations could be done in one step to avoid unnecessary database calls.

The route GET /document/:id/archive should return a 404 error if the specified id doesn't exist in the database, however it just returns an empty result with a 200 response.

The swagger API description file (https://app.swaggerhub.com/apis/epsilon32/UDV-Server/1.0.0#/) is globally correct but some informations are wrong.

• The return codes are copy / pasted for each requests and don't actually correspond to the API
• Some routes are not implemented (GET /comment/:id)

The route /user/me is supposed to return informations about the connected user, but it returns a lot more information than expected. All documents created by the user as well as all their comments are sent with the personal information. These can represent a lot of data and are not useful, they should be removed from the response.

Screenshot

The fields "comments" and "extended_document" should be removed.

Similar to #50, #51, #68, the route allow the doc info to be accessed by anyone

When a user updates a document, the "user_id" field of that document is also updated, overriding the original author.

A route should be accessible to delete existing links. An possible route scheme would be something like DELETE /link/<link_type>/<link_id> (example: DELETE /link/city_object/1).

Two routes exist that allow a client to upload for a document : POST /document (you can upload a file at the creation of the document), and POST /document/:id/file (you can specifically add a file to a document). However, the parameter corresponding to the file has different names in both cases (link in the first case, file in the second). For more clarity, they both should have the same name.

The route DELETE /guidedTour/:id/document/:id is described in the API specification but is not implemented in the server.

The swagger descriptor of the API (https://app.swaggerhub.com/apis/epsilon32/UDV-Server/1.0.0#/) specifies a route /comment/:id, which should accept GET, PUT and DELETE methods. However, only the PUT and DELETE methods are actually implemented in the API.