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
The last refactor of the save process (0fdb70ce66)
has introduced a bug: the save flow was not more stopped when a layer fail to save.
This ends with a broken UI, as the map is not dirty anymore, so the save button
is not active anymore, while at least one layer still needs to be saved.
Save can fail in two scenarios:
- there is a conflict (status 412)
- the server is down or as an issue (eg. disk is full)
I tried a more modest scenario (listening for status in map.save and
recallign the map save after a conflict), but this ended with calling
map.save uselessly even more.
So I decided to try this refactor, which also totally remove the useless
map.save we were sending at each save until now.
fix#2232
A classified layer needs to have compiled the data to known its
classes/categories.
This commit review the way we build the legend: instead of creating
with the whole caption panel, we just set a container and we populate
it later. This opens the door for live changing the legend when
editing the layer.
But we have to clarify that "reactive" pattern at some point, as we
have some concurrent pattern laying around: the `render()`, which
coupled with the schema and this is nice, but for now it's a bit rough
(changing the whole UI each time); the `propagate` way, which is
more specific, but not coupled to the schema; the `dataChanged`; and
the `onDataLoaded` now, which is a bit different, as it's about the
data being loaded, not changed/modified, but for the DOM it may at
the end be the same. Well, food for thoughts…
fix#2097
cf #1500
This is an alternative proposal for #2097:
- adding the button near the "Filter" toggle was a bit ugly, CSS/HTML
talking, because this "Filters" box is a details/summary
- I thought that other needs could live in the same place: a link to
download the filtered/visible data, and a button to show the map data
extent
The "toggle all" button works this way:
- if one or more layers are shown, it will hide those layers
- otherwise it will show all layers
I've preferred not to change the button icon according to map state,
because I didn't find a reliable way to do so, thus I'm afraid to have
inconsistency, but I can't try harder if needed.
Related: I'm thinking of adding a "Download" button for each layers, as
it's a request that comes quite often.
@Aurelie-Jallut could you have a look ? :)
The tricky thing is that the Map.is_owner() method check for cookies on
the request, but at create this cookie is not set yet on the request, so
we have to deal with an exception here.
fix#2176
The tricky thing is that the Map.is_owner() method check for cookies
on the request, but at create this cookie is not set yet on the
request, so we have to deal with an exception here.
fix#2176
The main issue was because we overrided the `getLatLngs` function in our
PointMixin class, so I changed the way feature get the latlngs from the
UI classes. Plus getting CircleMarker to inherit more from Marker,
through PointMixin.
fix#2171
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.
This bug has been introduced when spliting features, as we now only set
the Leaflet Polygon options with setStyle, will the `interactive` option
is only used in the init by Leaflet.
See https://github.com/Leaflet/Leaflet/pull/9475
- Operations are now stored locally in memory. All operations are tied
to an HLC (Hybrid Logical Clock), making it possible to order them
concistently.
- Messages are handled in their `on*` methods, leading to a clearer
implementation.
- When a new peer joins, it asks a random peer for the list of
operations, and re-apply them locally.
- Messages types names have been updated to follow CamelCase, and to be
similar across the client and the server.
- Pass `sync=False` to `makeFeature` in the updaters, to avoid
generating duplicate operations on message retrieval.
The main issue was because we overrided the `getLatLngs` function
in our PointMixin class, so I changed the way feature get the latlngs
from the UI classes.
fix#2171
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.
This bug has been introduced when spliting features, as we now
only set the Leaflet Polygon options with setStyle, will the
`interactive` option is only used in the init by Leaflet.
See https://github.com/Leaflet/Leaflet/pull/9475fix#2149
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.
This mainly allows to dynamically load the third party libraries.
In the same process, those libs have changed:
- tokml => switch to placemarkio fork, more up to date and available
as ESM
- togpx => switch to geojson-to-gpx, more up to date and available as
ESM (note: this lib does not export polygons, because they do not
make sense in GPX world, while the previous was converting them as
lines before)
Using [pytest-xprocess](https://pytest-xprocess.readthedocs.io/) proved
not being as useful as I thought at first, because it was causing
intermitent failures when starting the process.
The code now directly uses `subprocess.popen` calls to start the server.
The tests are grouped together using the following decorator:
`@pytest.mark.xdist_group(name="websockets")`
Tests now need to be run with the `pytest --dist loadgroup` so that all
tests of the same group happen on the same process.
More details on this blogpost:
https://blog.notmyidea.org/start-a-process-when-using-pytest-xdist.html
It is now using `WEBSOCKET_BACK_HOST`, `WEBSOCKET_BACK_PORT` and
`WEBSOCKET_FRONT_URI`.
We need to take in consideration that the "front" WebSocket address
(that clients will connect to) might be different than the "back" ip and
port which are bound in the host.
This happens for instance for reverse proxies, or when running inside
a container.
We considered using a `WEBSOCKET_TLS` setting, to try guessing the
"front" address based on `WEBSOCKET_HOST`, `WEBSOCKET_PORT` and
`WEBSOCKET_TLS`, but as the back and front address can differ, this
would need to introduce a `WEBSOCKET_URI` in any case, so we went with
just using it, and not adding an extra `WEBSOCKET_TLS`.
cf https://forum.openstreetmap.fr/t/umap-2-3-changement-de-gestion-des-pop-up/23680/3
Trying to make this panel expanded/condenses thing simpler and more intuitive.
It's mode can be set:
- by explicitely setting defaultPanelMode = xxx
- or, if defaultPanelMode is undefined, with sensible default when there is
an onLoadPanel defined, and to respect previous uMap behaviour
- or, if defaultPanelMode is unset, and some feature opens in the panel, it
will be set to expanded (here again to respect previous behaviour
- then, when user change it manually (by clicking on the toggle button), then
we should never change it automatically, and respect the previous mode when
reopening the panel
(We are only talking about the left panel, here.)
