Merge pull request #5113 from camptocamp/merge24

Merge remote-tracking branch 'origin/2.4'

ci/ci.yaml

@@ -1,2 +1,2 @@
 ---
-minor: 26
+minor: 32

doc/administrator/mapfile.rst

@@ -17,7 +17,7 @@ commonly named ``mapserver.map.tmpl``.
 .. note::
 
     The application's mapfile is a ``.tmpl`` file because it contains variables.
-    These variables are substituted when the ``make`` build command is executed.
+    These variables are substituted at container start.
 
 This section describes how to make layers *printable* and/or *queryable*
 and/or *private* (a.k.a *restricted*).
@@ -254,22 +254,21 @@ The ``${mapfile_data_noarea_subselect}`` is defined as follows::
 Metadata and filename
 ~~~~~~~~~~~~~~~~~~~~~
 
-It is required to have the following in the ``VALIDATION`` section of
-the ``LAYER``::
+It is required to have the following in the ``VALIDATION`` section of the ``LAYER``:
+
+.. code::
 
     ${mapserver_layer_validation}
 
-This variable is defined in the ``CONST_vars.yaml`` configuration file
-as follows:
+This variable is defined in the ``CONST_vars.yaml`` configuration file as follows:
 
 .. code::
 
     mapserver_layer_validation =
         "default_role_ids" "-1"
         "role_ids" "^-?[0-9]*$$"
 
-The mapfile should be a ``.map.tmpl`` file, for the variable to be
-substituted at make execution time.
+The mapfile should be a ``.map.tmpl`` file, for the variable to be substituted at container start.
 
 
 Variable Substitution

doc/administrator/tinyows.rst

@@ -21,7 +21,7 @@ The configuration of TinyOWS is made in a XML file, which is located at
 .. code:: xml
 
     <tinyows
-        online_resource="https://${host}/tinyows_proxy"
+        online_resource="https://${VISIBLE_WEB_HOST}/tinyows_proxy"
         schema_dir="/usr/share/tinyows/schema/"
         log_level="1"
         check_schema="0">
@@ -36,11 +36,11 @@ The configuration of TinyOWS is made in a XML file, which is located at
           title="GeoMapFish TinyOWS Server" />
 
       <pg
-          host="${dbhost}"
-          user="${dbuser}"
-          password="${dbpassword}"
-          port="${dbport}"
-          dbname="${db}" />
+          host="${PGHOST}"
+          user="${PGUSER}"
+          password="${PGPASSWORD}"
+          port="${PGPORT}"
+          dbname="${PGDATABASE}" />
 
       <layer
           retrievable="1"
@@ -57,7 +57,7 @@ The configuration of TinyOWS is made in a XML file, which is located at
 In the root element ``tinyows`` the following properties have to be set:
 
 * ``online_resource`` - This should be the URL to the TinyOWS proxy, usually
-  ``https://${host}/tinyows_proxy``.
+  ``https://${VISIBLE_WEB_HOST}/tinyows_proxy``.
 * ``schema_dir`` - The path to the TinyOWS schema directory. Adapt this path according to your installation.
 * ``log_level`` - The log level (default: 1). Please refer to the
    `TinyOWS documentation <https://mapserver.org/tinyows/configfile.html#tinyows-element>`__

doc/integrator/api.rst

@@ -12,10 +12,25 @@ In the file ``geoportal/demo_geoportal/static-ngeo/api/index.js`` you can custom
 
 .. code:: JavaScript
 
+   // The URL to the themes service.
    config.themesUrl = '<the theme URL>';
+
+   // The projection of the map, for example: 'EPSG:21781'
    config.projection = <the projection>;
+
+   // The resolutions list, for example: [250, 100, 50, 20, 10, 5, 2, 1, 0.5, 0.25, 0.1, 0.05]
    config.resolutions = [<the map resolutions>];
+
+   // The extent restriction, must be in the same projection as `config.projection`.
+   // the format is `[minx, miny, maxx, maxy]`, for example: `[420000, 30000, 660000, 350000]`
+   // the default is ǹo restriction.
    config.extent = [<the map extent>];
+
+   // The name of the layer to use as background, the layer must be present in the 'background_layers'
+   // section of the theme
    config.backgroundLayer = '<the background layer name>';
 
+   // The list of layers (names) that can be queried on mouse click
+   config.queryableLayers = [<layer a>, <layer b>, ...];
+
 The API help is in the folder ``geoportal/<package>_geoportal/static/apihelp/``.

doc/integrator/database.rst

@@ -1,47 +1,48 @@
 .. _integrator_database:
 
-========
 Database
 ========
 
-To be able to do a rollback the integration and the production data should be in the same database,
-but the schema will be different.
+Update lifecycle
+----------------
+The recommended setup is to have integration and production data on the same database, using
+separate schemas. This setup allows for simpler switches between integration and production.
 
-For the static schema will have one for the integration and one for the production environments, e.-g.:
+The recommended setup for the ``static`` schema is to have exactly one schema for integration
+and one for the production, e.-g.:
 ``integration_static`` for the integration environment,
 and ``production_static`` for the production environment.
 
-For the main schema will have one for each version of the application. We will have the following livecycle:
-
-Current version:
-integration and production => ``main_2017``
-
-Start an upgrade (application or admin (layertree)), create an new schema and use it on integration:
-integration = ``main_2018``, and production => ``main_2017``
-
-Do the changes or the upgrade.
-
-Publish the new version:
-integration and production => ``main_2018``
-
-The schema ``main_2017`` still exists to be able to rollback the production.
+For the data of the ``main`` schema, we recommend to have one schema for each version of the application.
+The following example shows how an update can be performed from a version ``2017`` to a version ``2018``:
 
-To do that we should manage the ``PGSCHEMA`` and the ``DOCKER_PGSCHEMA_STATIC`` variable in your
-makefiles.
+* Starting point is that the current version is the same on integration and production => ``main_2017``
+* When starting the changes, such as an application change and/or administration settings,
+  create a new schema ``main_2018`` and use it on integration. Now, integration uses ``main_2018``,
+  while production still uses ``main_2017``.
+* Do the changes or the upgrade.
+* Publish the new version on production: now, integration and production both use ``main_2018``
+* The schema ``main_2017`` still exists, so if needed, the production can be rolled back to this content.
 
-The ``PGSCHEMA`` should be set in the ``Makefile`` and the ``DOCKER_PGSCHEMA_STATIC`` for the
-production should be set in a specific makefile for the production e.-g. ``production.mk``.
+To be able to proceed like this, the variables ``PGSCHEMA`` and the ``DOCKER_PGSCHEMA_STATIC``
+should be managed in your makefiles:
 
 And the line `PGSCHEMA=main` should be removed from your `.env.sample` file.
 
-To copy the schema, we provide a Postgres function, to create it use:
+Copying a schema
+----------------
+To copy a schema, `c2cgeoportal` provides a Postgres function called `clone_schema`.
+If you have not created it in your database, use to following command to create this function:
 
 .. prompt:: bash
 
-   docker-compose exec geoporal psql <database> --file=scripts/CONST_clone_schema.sql
+   docker-compose exec geoportal psql <database> \
+       --file=scripts/CONST_clone_schema.sql
 
-To use it:
+To use the function, connect to your database and perform the following statement:
 
 .. code:: sql
 
-   SELECT clone_schema('<current_schema_name>', '<new_schema_name>', TRUE);
+    SELECT clone_schema(
+        '<current_schema_name>',
+        '<new_schema_name>', TRUE);

doc/integrator/tilegeneration.rst → doc/integrator/tilegeneration.rst.tmpl

@@ -83,7 +83,7 @@ Initialization
 
      TILECLOUD_CHAIN_LOCAL ?= TRUE
 
-  and set the ``wmtscapabilities_file`` to ``${WMTSCAPABILITIES_PATH}`` in your
+  and set the ``wmtscapabilities_file`` to ``${DOLLAR}{WMTSCAPABILITIES_PATH}`` in your
   ``tilegeneration/config.yaml.tmpl`` file.
 
 * In your ``<prod>.mk``, you can also set the capabilities file name with:
@@ -103,7 +103,7 @@ Configuration
 
 The configuration is done in the file
 ``tilegeneration/config.yaml.tmpl``. The original file is available at:
-https://github.com/camptocamp/tilecloud-chain/blob/master/tilecloud_chain/scaffolds/create/tilegeneration/config.yaml.mako_tmpl
+https://github.com/camptocamp/c2cgeoportal/blob/${MAIN_BRANCH}/geoportal/c2cgeoportal_geoportal/scaffolds/create/tilegeneration/config.yaml.tmpl_tmpl
 
 The main thing to do is to:
 

geoportal/c2cgeoportal_geoportal/views/mapserverproxy.py

@@ -55,6 +55,7 @@ def __init__(self, request: Request) -> None:
         self.user = self.request.user
 
     @view_config(route_name="mapserverproxy")
+    @view_config(route_name="mapserverproxy_post")
     def proxy(self) -> Response:
 
         if self.user is None and "authentication_required" in self.request.params: