This make it possible to synchronize datalayers before their creation on
the server, allowing at the same time to solve issues related to them
not being saved (e.g. duplication of geometries)
We use the DataLayer._referenceVersion to track if a DataLayer has been
saved on the server.
After a save, the _referenceVersion is synched with other peers.
To pass the reference version from the server to the frontend, we have two
options:
- use a header
- populate the `options.version` field
In the case of a GET on a Datalayer, we could not use the `options` scenario
because:
- the value in the file is not up to date (it was the value the client has
before the save)
- the python cannot change it on the fly, as the file is served by nginx
So we decided to keep using a header. But on the map view, we load all
datalayers metadatas in the map options, so here we cannot use the header
scenario, so in this specific case we had to populate `options._referenceVersion`.
At the same time, we also changed:
- Umap.options.umap_id => Umap.id
- DataLayer.umap_id => Datalayer.id
- fixed the version number returned by DataLayer.version_metadata
Until now, uMap was not deleting files on delete, which can increase
file storage a lot after some time.
The files are not deleted, but moved to a "purgatory" folder, from
where they can be deleted after some time.
In the same move, refactor the can_edit/_view/_delete functions to
only take the request, which is what really happen in the code, and
adapt the test in that way.
The goal being for it to be hidden for now.
- Add a `is_owner` method on the map and use it in the view
- Remove duplicated line in `global.js`
- Rename `Datalayer` to `DataLayer` everywhere
- Move the sync flag in the map options (next to slideshow)
There was an edge case when map has "dataLayersControl=expanded":
we only overrided "onLoadPanel", so dataLayersControl was still
considerer. Let's have a more generic stop.
This commit also introduce a new settings UMAP_SCHEMA, that could
be used to easily override schema default, like the default color, the
default path weigth and so on. I'm not documenting yet, because I'm
not yet totally sure we want this.
This allows to known the full datalayer behaviour without needing
to load all the data, including the zoom from and to (new settings),
but also the color for example.
This will help also understanding datalayers usage and making
stats.
But no data migration is provided, it's retrocompatible (data
migration in OSM FR servers would be huge, so let's see if it's
really needed).
