[Oskari-user] Oskari 2.10.0 released!

[Mäkinen Sami]

Good news everyone,

Fresh from the oven! The version 2.10.0 of Oskari has just been released! It is now available on GitHub (https://github.com/oskariorg) and Oskari.org Maven repository. The sample application package has been updated on the download link in Oskari.org (https://oskari.org/download) and http://download.osgeo.org/oskari/. As always you can take a peek at the latest release at https://demo.oskari.org/.

This time we have done some huge changes under the hood to improve maintainability and in preparation for an upcoming UI change.  We have polished the controls that are on the map with a new coat of paint (and scraped off some of the older layers in the process). This also allowed us to do more with theming and now users can customize their embedded maps with a new set of bells and whistles added to the publisher tool. Same for the geoportal but with less bells and/or whistles and more Java-code migrations and JSON content on the database. Anyways, it has been a while since the last release so buckle in for the wild ride of release notes below (also take a look at the https://github.com/oskariorg/oskari-server/blob/master/MigrationGuide.md when updating).

Release Notes
Oskari-frontend

For a full list of changes see: https://github.com/oskariorg/oskari-frontend/milestone/40?closed=1

Base HTML structure improvements

A set of new helper functions have been added for referencing "base elements" on the page and add CSS classes for styling these elements. All of this is about:

  *   ground work for an upcoming UI improvement
  *   making it easier to document things
  *   documenting the base elements to make it easier to customize
  *   cleaning of the base HTML (unnecessary elements have been removed from the base HTML on the sample-server-extension)
Prev. selector
JS-getter
New selector for styling
Role
body
Oskari.dom.getRootEl()
.oskari-root-el
Everything Oskari generates goes under here
#contentMap
Oskari.dom.getMapContainerEl()
.oskari-map-container-el
Container for the Oskari map
#mapdiv
Oskari.dom.getMapImplEl()
.oskari-map-impl-el
Container for map engine/impl (inside "contentMap")

The root element now defaults to element with id oskari or the body tag when not available. The oskari id can be used when the elements need to be controlled more tightly to work with other content on the page and Oskari should not take control of the page fully. Using the custom root element means that the size of the root element need to be set/controlled as well (is NOT handled by Oskari though we might introduce min-size in the future). If the whole page is controlled by Oskari the size is set to cover the whole browser window by assuming the root is the body tag.

The elements with ids contentMap and mapdiv are created under the root element if they are not present. The new CSS classes are attached automatically and have styling attached to them. The old id's have been kept for compatibility reasons and are no longer used by code under oskari-frontend. The JS getters should be used for referencing the elements (instead of the old id's) and CSS classes for styling. A helper Oskari.dom.isEmbedded() was also added for detecting if the app is an embedded map as some tools use this information.

For now the navigation bar that holds toolbar and tile/menu items of Oskari is assumed to be a <nav> element directly under the root element. The map elements are appended after it by default, but having for example the #contentMap element on the page before the nav controls which side of the map the navigation is. The Oskari flyouts now use this information to determine initial the Flyout location instead of hard coded values. The navigation element creation and content is planned to be moved to code as well as there are future requirements for making the navigation element more dynamic.

For more details see: #2042<https://github.com/oskariorg/oskari-frontend/pull/2042>

This change makes the map size handling much simpler:

  *   .oskari-map-container-el defines maximum size that the map can have
  *   .oskari-map-impl-el defines the size of the map itself (can be smaller than .oskari-map-container-el but not bigger. Used for example to preview publisher size setting)
  *   mapmodule bundle now monitors its own element size for changes without external notifications required
  *   MapSizeChangedEvent is still sent when the map size changes so other parts of the code base can react to size changes
  *   This makes the following requests unnecessary and they have been removed from the code base: MapFull.MapResizeEnabledRequest, MapFull.MapSizeUpdateRequest, MapFull.MapWindowFullScreenRequest

Theme

ThemeHelper<https://github.com/oskariorg/oskari-frontend/blob/2.10.0/src/react/theme/ThemeHelper.js> now has a function for easily getting theme selections that can be used for navigational elements like the buttons on the map: ThemeHelper.getNavigationTheme({...theme}) in a similar way that ThemeHelper.getHeaderTheme({...theme}) was previously used for windowing elements. The helper is still work-in-progress and comments about it are welcome. The idea is to provide getters that can try several settings from the theme JSON before returning a value for given theme variable. This way we can offer specific choices for theme setting but also provide fallbacks so a simple theme JSON could be given instead of giving a setting for every little detail in the theme.

Theme now also injects global style overrides to enable jQuery-based windowing elements have theming support and add initial theming support for the main navigation menu. See details in: #2100<https://github.com/oskariorg/oskari-frontend/pull/2100> This is similar to what Oskari-based applications do to override the default colors.

Map theme

Handling for a new subobject named "map" was added to the theme enabling the map controls to use similar theme structure as the rest of Oskari application but individual toggles that can be adjusted just for the map. An example would be a case where the buttons on the map and the popups they open need to have a different color scheme as the rest of the geoportal. This was the case before theming support where the default UI on Oskari had yellow colored flyouts/popups, but similar components opened by buttons on the map had dark headers instead.

The way the "map" theme works is it can have the same structure as a normal theme JSON, but the mapmodule generates a theme for itself by combining the geoportal theme and overriding it with keys from the map subobject. As an example:

{

    color: {

        primary: 'yellow',

        accent: 'red'

    },

    map: {

        color: {

            primary: 'gray'

        }

    }

}

The mapmodule uses its own ThemeProvider context for its components. The map components would (in the example above) get a theme where the primary color is gray while non-map components would see the primary color as yellow. Both types of components would see the accent color as 'red' as it's not overridden under the map key. The mapmodule has set/getMapTheme() methods and it listens to changes on the geoportal theme to update the theme for map components.

Some of these are listed in #2069<https://github.com/oskariorg/oskari-frontend/pull/2069> and this will be documented in more detail in oskari.org.

Publisher functionality

Enabled by the new theme support the publisher functionality now includes an initial theme editor for the embedded maps. This allows the end user to select for example colors that affect the controls on the map and the popups they open. The visual options that were previously offered have been changed to preset values for the new theme editor so they can be used as a starting point for more customized theme.

The tool placement/dragging mode in publisher now shows handles for tools as a visual reminder that tools can be dragged. Most restraints for plugin placement have been removed so they can be moved more freely.

Draw tools

The drawtools bundle has been rewritten to make it easier to read and maintain. When requesting buffered features for drawing, they are now generated for all features in a multi feature collection. An issue has been fixed on perimeter/outer ring length measurements for polygons. The measurement tooltips no longer block clicks on the map so it's easier to edit measurements. Updated StopDrawingRequest documentation to match implementation.

Map controls

All of the map controls (buttons on top of map etc) that are included in oskari-frontend have been rewritten as React-based components. They can now be styled using theme variables and have icons changed to SVG enabling hovering and more flexible styling options. The popups they open are theme-aware as well and some of the controls gained new functionalities:

  *   Search can now be minimized to a smaller icon when clicked on the map
  *   The previous pan buttons tool now only shows the reset button by default but it can be configured (using publisher UI) to show the arrows when required
  *   The concept of "mobile mode" with the toolbar on top of the map has been removed
  *   Tools now modify their own UI to fit a smaller screen more properly. As an example the zoombar hides its slider and makes its buttons bigger.

To make it easier to migrate any customized plugins to the new plugin structure the deprecated methods in BasicMapModulePlugin.js have been kept as no-op functions with logging to tell developers they should migrate a plugin that uses them:

  *   getMobileDefs()
  *   removeToolbarButtons()
  *   addToolbarButtons()

For details see: #2082<https://github.com/oskariorg/oskari-frontend/pull/2082>

Also documentation about customization for some common cases can be found in:

  *   https://oskari.org/documentation/customize/logo
  *   https://oskari.org/documentation/customize/indexmap

Build scripts

Parameters can now be passed on command line in another way (#2064<https://github.com/oskariorg/oskari-frontend/pull/2064>) Both of these work with version 2.10:

npm run build -- --env.appdef=applications

npm run build --appdef=applications

Build script now allows generating builds to non-default domain with parameter: --env.domain=https://cdn.domain.org.

New React components

  *   MapButton under oskari-ui for generic button on the map
  *   MapModuleButton under mapmodule uses MapButton and adds theme handling
  *   SidePanel under oskari-ui is currently used for printout options panel (publisher and others will be migrated to this in future release)
  *   Tooltip component should now clear from the screen properly when the element they are attached to is not shown

Other improvements

  *   VectorTileLayerPlugin now receives the actual map resolutions array instead of using OpenLayers defaults. This might affect styling of vector tile layers: #2115<https://github.com/oskariorg/oskari-frontend/pull/2115>
  *   Thematic map now allows classification with 2 values if method is not jenks and histogram view has been improved
  *   Fixed issues with layer list in embedded map: layers are now listed in correct/reversed order and style select is no longer shown if there is only one style to select from
  *   Added bundle documentation for mydata
  *   Fixed a visual issue with infobox title
  *   Fixed an issue with opacity setting and vector layer features in 3D
  *   My places now checks polygon feature validity so users can't save a self-intersecting polygon
  *   Fixed an issue with userlayer import: input for providing missing projection information is now shown when required
  *   Printout options panel has been rewritten with React
  *   Added a workaround for OpenLayers issue with features having a property named geometry: #2110<https://github.com/oskariorg/oskari-frontend/pull/2110>
  *   Metadata search (metadatacatalogue) bundle can now function without the search bundle being present in the application. It now creates its own tile/menu item if it can't inject itself into the normal search UI.
  *   Library updates:
     *   OpenLayers 7.1.0 -> 7.2.2
     *   moment.js 2.29.1 -> 2.29.4

oskari-server

For a full list of changes see: https://github.com/oskariorg/oskari-server/milestone/44?closed=1

Service customization

Appsetups can now have a theme JSON in the database table oskari_maplayer.metadata under the key theme. This enables embedded maps with user defined theme and it can also be used to customize the geoportal views. On the same note, the map tools no longer have "toolStyle" or "font" config and the previous selections made in publisher for embedded maps have been migrated to theme JSON in the database.

The theme can now be provided as part of an initial appsetup JSON when initializing an Oskari-based application programmatically: #909<https://github.com/oskariorg/oskari-server/pull/909> (See sample-server-extension https://github.com/oskariorg/sample-server-extension/blob/7f499fc51147be981108ef2536788c5cc811417c/app-resources/src/main/resources/json/apps/geoportal-3067.json#L12-L50).

See migration notes for more information about theming changes.

A centralized helper class org.oskari.util.Customization was added for getting markers and service logo and make customization easier. The logo can be customized for Oskari instance using oskari-ext.properties and we could enable overriding the markers in a similar way in the future. Previously markers were duplicated on the server code for frontend and printouts and service logo was also usually duplicated in frontend code as well. Added a new action route Logo that is used by frontend to get the service logo from server so customizing it doesn't require frontend modifications and CSS overrides. See details: #901<https://github.com/oskariorg/oskari-server/pull/901>

Added initial implementation for frontend code versioning. The main audience for this are maintainers of RPC-based applications, but it can be used on geoportal as well. This allows the maintainer of an Oskari instance to provide parallel frontend code support on an Oskari instance that can be toggled with url-parameter. This could be used to provide more flexible update schedule for RPC-based applications. See: oskariorg/oskari-docs#32<https://github.com/oskariorg/oskari-docs/issues/32> & #897<https://github.com/oskariorg/oskari-server/pull/897>

The domain (/cdn where static code is hosted) for client code can be configured using oskari-ext.properties. This enables running the same server-side code in environments using frontend code from a CDN/another domain and for example local dev environment: oskariorg/sample-server-extension#33<https://github.com/oskariorg/sample-server-extension/pull/33>

The link back to geoportal on the embedded map logo can now be disabled by configuring plugin.logo.geoportalLink=false in oskari-ext.properties.

Metadata search improvements

The search is now requesting the result (ElementSetName) as summary instead of full so it contains less data to parse (and for the CSW-service to respond with). Also the query fields can now be configured to make the queries even lighter for the CSW-service (csw:anyText seems to be very heavy if there is a lot of data on the service): #912<https://github.com/oskariorg/oskari-server/pull/912>

# Valid values: summary, brief, full (defaults to "summary")

search.channel.METADATA_CATALOGUE_CHANNEL.queryType=summary

# comma-separated list - defaults to csw:anyText

search.channel.METADATA_CATALOGUE_CHANNEL.queryFields=Title, Abstract

The brief setting is even lighter, but by using it the search results won't include the date or organization on them as it's not included in that data set. Setting the query fields seems to be more effective way of getting more performance if it is an issue for the search.

The search configuration has been streamlined with just service.metadata.url in oskari-ext.properties used to configure the CSW endpoint. Many of the duplicated properties can be cleaned up/removed from oskari-ext.properties as listed in #910<https://github.com/oskariorg/oskari-server/pull/910>

The search result parsing code has been rewritten to reduce dependencies and improve maintainability. Sanity checks have been added for data as some services might have invalid data for example on the bounding boxes: #917<https://github.com/oskariorg/oskari-server/pull/917>

Cloud compatibility improvements

The database connection/pool is no longer using JNDI by default. Connection pool can still be passed through JNDI, but the code doesn't try creating a context if it's not available. Previously Oskari tried adding the database JNDI config to the context if it was not there to begin with. This led to problems with for example Tomcat environments where the JNDI-context is read-only. This forced using JNDI configuration on environments using Tomcat. Using JNDI in context required the JDBC driver to be on Tomcat classpath and the driver could not be bundled inside the webapp war-file which makes cloud deployment in for example Azure App Service more painful than it needs to be.

Now the JDBC driver can be bundled in the war-file and the database configuration passed in oskari-ext.properties can be used to connect to the database even on Tomcat: #916<https://github.com/oskariorg/oskari-server/pull/916>

New Redis integration configuration options have been added for oskari-ext.properties:

# Can be used to set password if connection requires one

redis.password={your password or remove config to leave empty}

# When using SSL-connections (defaults to false like previously)

redis.ssl=true

# Timeout for connection (2000ms is the default timeout in Jedis)

redis.timeout.connect=2000

Redis-config redis.pool.size is now passed to connection pool max-total as expected. Previously it was only used to calculate and set the max-idle.

Caching in clustered environment has been improved by implementing the "flush all" command for cluster cache communication: #902<https://github.com/oskariorg/oskari-server/pull/902>. This fixes an issue where updates to map layers were not always reflected on all the nodes of a cluster until reboot.

Reduced noise on logs

OskariComponent subclasses can now use org.oskari.component.ComponentSkippedRuntimeException (in service-base module) on the init method instead of using some other exception to signal that they are not configured properly to work/need to be skipped based on the instance config. This is used in What3WordsSearchChannel (in service-search-opendata module) as most instances don't use the channel (or don't have an apikey for it) it's unnecessary to log the stack trace for the channel just so we can disable it based on missing configuration. Now the startup of oskari-server has less misleading stack traces that the admin doesn't need to care about. See #888<https://github.com/oskariorg/oskari-server/pull/888> for details.

Also moved some common/spammy informational logging from log level info to debug.

Other improvements

  *   Service logo configured for printouts can now be non-square. The scalebar in printout makes space for logo when required.
  *   Fixed an issue with map legends for proxied map layers without legends
  *   Fixed an issue with WTMS coordinate order: #920<https://github.com/oskariorg/oskari-server/pull/920>
  *   Allow hyphen/dash in email domain name #924<https://github.com/oskariorg/oskari-server/pull/924>
  *   Automatically disable the "no status available" tooltip for layers when the statuses are not available at all on an instance: #922<https://github.com/oskariorg/oskari-server/pull/922>
  *   Allow list of bundles that can be part of an embedded map is now fully on server-side code. This makes it easier to enable custom bundles as part of publisher options: #921<https://github.com/oskariorg/oskari-server/pull/921>
  *   Library updates:
     *   Spring 5.3.18 -> 5.3.20
     *   Spring security 5.6.2 -> 5.7.0
     *   Spring session BOM 2021.1.2 -> 2021.2.0
     *   commons-lang3 3.11 -> 3.12.0
     *   commons-text 1.9 -> 1.10.0
     *   commons-code 1.7 -> 1.15
     *   commons-dbcp2 2.8.0 -> 2.9.0
     *   PostgreSQL JDBC 42.5.0 -> 42.5.1
     *   MyBatis 3.5.7 -> 3.5.11
     *   Jackson 2.13.2 -> 2.13.4
     *   Jackson databind 2.13.4 -> 2.13.4.2
  *   Removed unused dependencies from managed dependencies (code using these have been removed/rewritten):
     *   org.apache.xmlbeans.xmlbeans
     *   org.codehaus.woodstox.stax2-api
     *   com.fasterxml.woodstox.woodstox-core

Cheers,
    Sami
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/oskari-user/attachments/20230221/41f37cdb/attachment-0001.htm>