- always redirect user from map to their profile page when they
used a deprecated backend to log in
- change the Twitter image to make clear it is to be removed
Co-authored-by: David Larlet <david@larlet.fr>
When deleting a datalayer, it will now be moved to a state "deleted", and
it will only be deleted for real when running the command `umap empty_trash`.
This is what we already do for the map itself, but until now if a user
deleted a only a datalayer by mistake (not the map itself) it could not retrieve
it.
This should only be used in localhost, but there are a bunch of
check and it's often that we need to add print to understand why
the URL does not validate, which is usually an issue with the SITE_URL
or this kind. So let's make those print permanent.
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 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
- 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.
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.
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`.
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)
`WEBSOCKET_ENABLED`, `WEBSOCKET_HOST`, `WEBSOCKET_PORT` and
`WEBSOCKET_URI` have been added.
They are being transmitted to the client via the `map.options`.
When `WEBSOCKET_ENABLED` is set to `False`, the client doesn't have
the ability to be synced.
Authentication is now done using a signed token provided by the Django
server, sent by the JS client and checked by the WebSocket server.
The token contains a `permissions` key that's checked to ensure the user
has access to the map "room", where events will be shared by the peers.
