=== Getting it to the mobile client ===
Next, we want to make sure the mobile client receives your DynSL.
* Create a new [[QUERYSCOPE|query scope]] instance for the DynSL. Let's call it "QCS_DYN_SL" for example.* Assign the DynSL instance to the new query scopeby dragging the DynSL instance onto the "QUERY" field of the scope instance.
* Add the [[SYSCLS_OFFLINE_QUERY|Offline Query Classification]] to the scope.
* Add the [[SYSCLS_DYNAMIC_SELECTIVE_LIST|Dynamic Selective List Classification]] to your scope as well.
* Add the "QCS_DYN_SL" to the scope list of your ACM [[CONTEXT|context]].
* Add the "DynSL" instance to the infrastructure list of your ACM context.
== Goal 2: Create items for the Dynamic Selective List ==
* Since our items have gained a security clearance now, we also have to send it to the client. Add the new meta property to the scope "MCS_DYN_SL_ITEM".
* Of course, we also want to have our department on the client. Also, the department should be a root object, and our test object "InstanceWithDynSL" should be below that department in the content hierarchy on the client. We trust you know how to achieve this!
* The department scope "MCS_DEPARTMENT" should also have the new meta property "MP_REQUIREMENT" as a scoped meta property.
So now, we've created a dependency property telling us why some of our items can be selected and some of them can't.
{{Hint|The dependency object specifying the value influencing the selectable items must be either the target object (the one with the DynSL property), or anywhere above it in the hierarchy.}}
== Goal 5: Add a criterion to connect the dots ==
Now that we have documented our security clearance criterion, we just have to tell the client.
* For this purpose, create a meta class scope "MCS_DYN_SL_CRITERION" for the meta class "MC_DYN_SL_CRITERION".
* Add the [[SYSCLS_DYNAMIC_SELECTIVE_LIST_CRITERION|Dynamic Selective List Criterion Classification]] to the scope.
* All the meta properties described above should also be added to the scope.
* Add the scope to the list of all scopes of your ACM context.
* Add the criterion instance ("SecurityClearanceCriterion") to the list of infrastructure objects.
* The new criterion must also be reflected on the dynamic selective list scope, because we need it for the offline query aspect of this feature: Add the meta property "MP_SECURITY_CLEARANCE" to the DynSL scope "QCS_DYN_SL". The reason for this is, that the DynSL is an offline query and requires a property to contain the criterion value. This value is resolved using the DynSL criterion.
{{Hint|Multiple criteria with different dependencies are supported. It is also possible to omit the dependency class restriction, so the closest object with the dependency property (ignoring the meta class) is used as dependency.}}
You can configure Dynamic Selective Lists to allow much more complex scenarios. For example, you can remove the restriction for the dependency class on the criterion. You can define the target object as the dependency object, too, so it depends on a different property of itself. You can even specify multiple criteria, potentially with different dependency objects. It is also possible to define multiple properties with dynamic selective lists depending on each other successively.
== Known issue workaround: Not ignoring NULL criteria doesn't work ==
One of the features of DynSL is to specify a criterion with the dependency value NULL that should only yield items with the criterion property value NULL (instead of just yielding every result). This can be achieved by setting the criterion's "IGNORE_NULL" property to False and the dependency property value to NULL.
Or rather, it should be achieved that way; there is a bug on the WinX client in version 4, which basically always ignores null values no matter the criterion configuration. Fortunately, there's a workaround:
If you override the dependency property in customizing programmatically, so it always returns any value definitely never occurring "in the wild" instead of NULL, and do the same for the item's criterion property, you achieve the desired result. We're working on fixing the bug, but in the meantime this should help you work around it.
<source lang = "csharp">
// do this for both the dependency property as well as the item's criterion property
var val = base.MY_PROPERTY;
return val ?? "NULL"; // this is the same as saying, 'If the value is not null, use it. Else, use whatever I wrote after the "??" operator'
</source>
Why does this work? Currently, the client handles NULL values differently than regular values (ignoring them, basically). However, with the above code you're changing a NULL into a regular value, so there's no extra behavior.
<!-- = Studio = -->
<!-- DO NOT REMOVE THIS -->{{Template:HowTo/End}}<!-- DO NOT REMOVE THIS -->
[[Category:Client|Configure Dynamic Selective Lists]]
[[Category:How-To|Configure Dynamic Selective Lists]]
[[Category:Studio|Configure Dynamic Selective Lists]]
[[Category:Web service|Configure Dynamic Selective Lists]]
==See also==
* [[HowTo:Configure_the_ACM]]
* [[HowTo:Make_an_Object_appear_on_the_Mobile_Client]]
* [[HowTo:Make_a_Property_editable_on_Mobile_Client]]
[[Category:Client|Configure Dynamic Selective Lists]]