...

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 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.

...

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 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.

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.

Configuration

Namespace

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

...