...

To apply a filter to another item in Weave the item would need to support filtering in the first place, you should refer to the configuration wiki page for the particular item to see if it supports filtering.For example, if

Data Definition

If you wish to apply the filter to a data definition that uses a database table to retrieve data then the filter can be added as an SQL Where clause in the data definition configuration. This is possible because the dayasourcedataconnection datasourcedataconnection type of data definition provides support for filtering using SQL via the where tag, where-as an inlinedataconnection does not (currently) support filtering so cannot use a dynamic user attribute to refine the returned data.

<?xml version="1.0" encoding="UTF-8"?>

<config xmlns="urn:com.cohga.server.config#1.0" 
	xmlns:data="urn:com.cohga.server.data.database#1.0">

	<data:datadefinition id="trees">
		<datasourcedataconnection datasource="database" table="trees" key="id" prefix="DISTINCT">
			<where clause="insp_date = ${user.dynamic.trees.insp_date}"/>
			<parameter typeid="string" name="species" label="Species" column="species"/>
			<parameter type="string" nameid="location" label="Location" column="location"/>
			<parameter type="date" nameid="insp_date" label="Insp. Date" column="insp_date" type="date"/>
		</datasourcedataconnection>
	</data:datadefinition>

</config>

...

The values the user enters for the filter are referenced using the format:
${user.dynamic.<filterid>.<parameterid>}
and in some situation the value set for the filter parameter may require coercion to convert it to the format required by the underlying provider (e.g. database, spatial engine, etc), for example some databases may require a CAST or CONVERT function to wrap the value provided by the filter to ensure it is in the format that the database requires. Take note that since this is new functionality there may also be issues with the conversions that should be, or even need to be, handled by Weave, so if you’re having issues getting a particular dynamic user attribute to with contact support for help.

Spatial Mapper

The above example configuration just applies the filter to a single data definition associated with the trees but in all likelihood you will have additional configuration items which would also make sense to have the filtering applied to, for example you could apply the filter to the spatial mapper for the trees entity so that when a user tries to select a tree spatially with one of the map selection tools only those trees that meet the filter restrictions would be selected.

<?xml version="1.0" encoding="UTF-8"?>

<config xmlns="urn:com.cohga.server.config#1.0" 
	xmlns:mapper="urn:com.cohga.server.spatial.mapper#1.0">

	<mapper:mapper id="trees">
		<spatialEngine>spatialengine</spatialEngine>
		<mapping>
			<entity>trees</entity>
			<table>trees</table>
			<key>id</key>
			<filter>insp_date = ${user.dynamic.trees.insp_date}</filter>
			<dynamic>true</dynamic>
			<cache>false</cache>
		</mapping>
	</mapper:mapper>

</config>

Maps

Or you could apply the filter to the map engine that displays the trees so that only the trees that meet the filter criteria will be drawn on the map.

<?xml version="1.0" encoding="UTF-8"?>

<config xmlns="urn:com.cohga.server.config#1.0" 
	xmlns:filter="urn:com.cohga.weave.map.filter#1.0">

<!-- currenty map layer filters are not defined directly in the map engine itself
but are a separate configuration item in their own right.
In this case we're creating a user map layer filter and referencing the dynamic user attribute -->
	<filter:user id="trees">
		<mapengine>mapengine</mapengine>
		<layer>trees</layer>
		<filter>insp_date = ${user.dynamic.trees.insp_date}</filter>
	</filter:user>

</config>

Searches

A filter can also be applied to attribute searches.

...

By applying the filtering to each item that’s related to the trees then the end user will have a consistent filtered view of the data related to the values they entered for the filter, which is the intended use case of thing functionality.this functionality.

Indexes

Applying a filter to an index is a little more involved than some of the other items in that it requires that additional fields be added to the index when it is built.

<?xml version="1.0" encoding="UTF-8"?>

<config xmlns="urn:com.cohga.server.config#1.0" 
	xmlns:data="urn:com.cohga.server.data.database#1.0"
	xmlns:index="urn:com.cohga.server.index#1.0">

  <data:datadefinition id="idx.trees">
		<datasourcedataconnection datasource="database" table="trees" key="id" prefix="DISTINCT">
			<parameter id="species" label="Species" column="species"/>
			<parameter id="location" label="Location" column="location"/>
			<parameter id="insp_date" label="Insp. Date" column="insp_date" type="date"/>
		</datasourcedataconnection>
	</data:datadefinition>
	
	<index:entity id="idx.trees">
		<entity>trees</entity>
		<datadefinition>idx.trees</datadefinition>
		<display>
			<level1>Tree ${species}</level1>
			<level2>${location}</level2>
		</display>
		<keywords>
			<level1>tree</level1>
			<level2>${species}</level2>
		</keywords>
		<fields>
			<field name="dynamic.tree.insp_date" value="insp_date"/>
		</fields>
	</index:entity>

</config>

In the above example the additional fields to be added to the index (there can be more than one) are added with the <field> tag. The name attribute is the name of the attribute that will be added to the indexed document, and must be in the format dynamic.<filterid>.<parameterid>, and the value refers to the parameter in the data definition that will provide the value for that field.

Then when the index is searched the query will include additional context to ensure that if the user attribute for the parameter, in the above example the insp_date user attribute, is set then it will be included in the query to ensure that only documents that contain the matching value in the dynamic.tree.insp_date field are included in the results.

If the insp_date user attribute is not set then the query will not be adjusted to include a reference and all documents will be searched.

Client

Once you have the filters configured and the various other configuration items setup to use the filters you need to add the filter panel to the client so that the user can modify the parameters for the filter(s).

There is no specific configuration that is available for the panel so you just need to include a label and location. The id for the panel is weave.userAttributes.

			<view id="weave.userAttributes" label="Data Filters">
				<location>east</location>
			</view>

Configuration

Namespace

urn:com.cohga.weave.dynamic.attributes#1.0

Tags

config

...

Properties

Sub-tags

parameter

...

Properties

Sub-tags

list

...

Properties

Data Security

To ensure that data is not accidentally exposed because of an incorrectly configured filter if the value for a user property is missing then filtering will convert the generated filter into one that returns no results rather than just removing the filter and returning all results, e.g. a filter like where client_id = ${user.dynamic.client_id} will be replaced with something like where 1 = 0 if there is no dynamic value for the client_id.

Normally you would resolve this by providing a suitable default value for the client_id, e.g. where client_id = ${user.dynamic.client_id|9999999}, which would result in the same outcome in this example, but make it explicit what is happening and shows that the issue has been looked at. Alternatively, you can set a property that changes the handling of the filtering to remove the filter if the value is missing.

The property to set is weave.ignoreonsubstitutionerror and if it is set to true then the handling of missing values will be treated differently and will result in the filter being excluded and all results (subject to any other filtering) will be returned rather than no results. The value can be set as a system property or just adding the following to a config xml file:

<?set weave.ignoreonsubstitutionerror=true?>