Legacy Product

Fusion 5.10
    Fusion 5.10

    Appkit SDK 4.4.0 Release Notes

    Release date: 22 July 2019

    Upgrading to this version

    In apps created with prior versions of Fusion App Studio, you can upgrade the Appkit version to 4.4.0.

    If you are upgrading to 4.4.0 from a version prior to 4.3.0, additional upgrade steps are required or recommended.

    Recreate topics that contain non-URL-safe characters

    An issue in the Social Module in prior releases prevented topics that contained non-URL-safe characters from loading correctly in browsers.

    The fix in this release allows future topics to contain URL-unsafe characters; the topics load correctly. But this release does not repair existing topics.

    To repair existing topics, you must delete and recreate the topics.

    New features

    Elasticsearch search platform supports geo-filtering and sorting

    The Elasticsearch search platform now supports geo-filtering and sorting based on distance.

    Filter syntaxes

    These are the filter syntaxes. The unit property is optional. If not present, the default unit kilometers is used.

    f=geo-point-field[{"lat":latitude-value,"lon":longitude-value,"distance":distance-value}][display-value]

f=geo-point-field[{"lat":latitude-value,"lon":longitude-value,"distance":distance-value, "unit":"unit-value"}][display-value]

    Filter properties

    Property Required Notes

    lat

    required

    Latitude value (decimal, for example, 37.773972)

    lon

    required

    Longitude value (decimal, for example, -122.431297)

    distance

    required

    Distance from a latitude/longitude point (a positive real number, for example, 10 or 2.5)

    Do not specify the distance units as a part of distance (as you would in Elasticsearch). Use unit instead.

    unit

    optional

    Units of distance. Possible values are the long form distance units, that is, miles, yards, feet, inch, kilometers, meters, centimeters`, millimeters, and nauticalmiles. The default is kilometers.

    Sorting

    The syntax of the URL query parameter for sorting on a geo_point field is the same as for other sorting (+ for ascending, - for descending):

    s=+geo-point-field

s=-geo-point-field

    Example queries with geo-filters

    Explicit query, default units (kilometers):

    http://localhost:8080/#/search?q=*:*&f=pin.location[{"lat":40,"lon":-70,"distance":200}]["Within 200 km"]

    Implicit query, non-default units (miles):

    http://localhost:8080/#/search?f=pin.location[{"lat":40,"lon":-70,"distance":200,"unit":"miles"}]["Within 100 miles"]

    Implicit query with sorting (descending), default units (kilometers):

    http://localhost:8080/#/search?f=pin.location[{"lat":40,"lon":-70,"distance":1000}]["Within 1000 km"]&s=+pin.location

    End-to-end example

    In Elasticsearch

    1. Create an index. For example:

      curl -X PUT "localhost:9200/map_locations" -H 'Content-Type: application/json' -d'
{
    "settings" : {
        "number_of_shards" : 3,
        "number_of_replicas" : 2
    }
}
'

    2. Apply a geo-point mapping to a field in the index. For example:

      curl -X PUT "localhost:9200/map_locations" -H 'Content-Type: application/json' -d'
{
    "mappings": {
        "_doc": {
            "properties": {
                "pin": {
                    "properties": {
                        "location": {
                            "type": "geo_point"
                        }
                    }
                }
            }
        }
    }
}
'

    3. Index documents that contain one or more fields of type geo_point (any of the four formats). For example:

      curl -X PUT "localhost:9200/my_locations/_doc/1" -H 'Content-Type: application/json' -d'
{
    "pin" : {
        "location" : {
            "lat" : 40.12,
            "lon" : -71.34
        }
    }
}
'

curl -X PUT "localhost:9200/my_locations/_doc/2" -H 'Content-Type: application/json' -d'
{
    "pin" : {
        "location" : {
            "lat" : 42.12,
            "lon" : -74.34
        }
    }
}
'

curl -X PUT "localhost:9200/my_locations/_doc/3" -H 'Content-Type: application/json' -d'
{
    "pin" : {
        "location" : {
            "lat" : 0.12,
            "lon" : -1.34
        }
    }
}
'

    4. In the Elasticsearch configuration file elasticsearch.yml, identify the field or fields that are of type geo_point. For example:

      geo-point-fields: pin.location
    In Appkit

    1. Perform a search with a filter that identifies a geo_point field and specifies a latitude, a longitude, and a distance (and optionally units). For example:

      http://localhost:8080/{hash}/search?q=*:*&f=pin.location[{"lat":40,"lon":-70,"distance":200}]["Within 200 km"]

    2. Optionally, include an s (sort) query parameter to sort search results on a geo_point field that was used in a filter; for example, s=+pin.location (ascending) or s=-pin.location (descending). For example:

      http://localhost:8080/{hash}/search?q=*:*&f=pin.location[{"lat":40,"lon":-70,"distance":200}]["Within 200 km"]&s=+pin.location

    3. The Elasticsearch platform performs an Elasticsearch geo_distance query, which finds documents with at least one geo-point that falls within the specified distance of the specified point (and that satisfy any other query and filter criteria), and returns a response that lists the documents. If the s query parameter was included, the documents listed in the response are sorted in order of distance from the specified point.

    Improvements

    Appkit filter syntax supports complex filter values

    Previously, the Appkit filter syntax supported a small number of simple data types (string, boolean, integer, double, and date) and ranges over simple data types.

    With this release, the Appkit filter syntax adds support for an object data type that can specify filters of arbitrary complexity. The object data type uses JSON syntax to describe the data. For example, a filter can specify unordered lists of name/value pairs (objects) and ordered collections of values (arrays).

    For example:

    data[{"property1":"some_text","property2":34,"property3":true,"property4":9223372036854775807,"property5":53.4678,"property6":["a","b"],"property7":{"key1":"value","key2":56}}]["A filter object"]

    Security providers return 401 Unauthorized for unauthenticated API requests

    All Appkit security providers that use Spring security now return a 401 Unauthorized status for unauthenticated API requests. Previously, they returned a 403 Forbidden status.

    Additionally, for the SAML security provider, the standard AJAX request handling mechanism has been included, which means that 302 Found redirects do not occur for unauthenticated API requests.

    The security providers affected are:

    • Active Directory

    • Twigkit Cookie Cracker

    • Lucidworks Fusion Sessions API

    • Kerberos

    • LDAP

    • ADFS OAuth

    • Facebook OAuth

    • Google Oauth

    • Office 365 OAuth

    • SAML

    • Spring Security

    Histograms and sliders work with small timeframes

    Histograms and sliders now work correctly with date ranges that have small timeframes, for example hours or minutes.

    The filter-optional attribute has been added to <search:field>

    When using <search:field> to make a field clickable in order to refine the current query, you can now define the filter-optional tag attribute. This tag attribute tells Appkit how to combine filters using connective logical operators.

    For example, when you have a multi-select (checkboxes) facet defined on the same field and displayed on the same page as a clickable field for refining a query, you must specify filter-optional to be value in the filter for the facet directive.

    For more information, see Optional logical operators.

    Bug Fixes

    • Click tracking for instant results (<instant:result-list>) now returns the correct query object in the tracked-click object. These are examples of markup and a response object:

      <search:box placeholder="Find documents..." action="search" social="true" query="query">
    <track:clicks query="query">
    <!-- Instant Results -->
    <div>
        <instant:result-list platform="platform" query="query">
            <search:result>
                <search:field name="title" styling="title" urlfield="url"></search:field>
            </search:result>
        </instant:result-list>
    </div>
    </track:clicks>
</search:box>
      {
id: "quickstart/Revolution-Session-Data.csv#36",
label: "Passage Search: the Answer to Your User Questions!",
offset: 0,
pos: 3,
query: {rpp: "14", fa: "keywords_s", p: 1, q: "sa*"},
type: "result",
url: "http://localhost:8090/quickstart/Revolution-Session-Data.csv#36"
}

    • When using the Social module, topics that contain non-URL-safe characters (for example, #) now load in browsers correctly, if the comments were created using this software version, 4.4.0.

      This release does not repair existing topics that contain non-URL-safe characters. You must recreate those comments.

    • When using the <search:field> tag, fields with no value are no longer clickable.

    • The localization key collaborate.saved.placeholder was added for the hint text in the search box for the collaborate:saved-query-list tag. The search box lets the user search through a list of saved queries. The default English hint text is Search name.

    • The root context page is now an allowed login location.

    • When grouping results, the first related result no longer shows values for all related results.

    • When grouping results using the platform groupField parameter, the first result in a group of results now contains only its own metadata. Previously, the first result contained the metadata of all of the results in the group.

    • The <widget:date-range> tag now completely clears dates when the date filter is cleared.