RSA supplied Database
version 7.1.1 P1
Is it possible to use the LIKE under the Advance rule screen?
Example: user.Title LIKE 'Director%'
You do not even have to use the Advanced filter. String fields allow you to chose the operator "contains" which expands to like in the advanced filter. Something is odd with the particular example that you chose "Title". For some reason this attribute is not being evaluated as a searchable string. Be aware that everything has a cost. Partial matches of course result in SQL queries that are more expensive.
a little extra info: %Searchterm% is way more expensive than %Searchterm or Searchterm%. The "Contains" is equal to %Searchterm%. So if one knows that the part string is indeed at the very beginning or end, better to use the advanced query and go for the specific wildcard search.
Thank you Ian.
I wanted to also add that if I type it in the Advance screen it works, but when I go back to modify, it shows me the simple screen and Title is Null.
Does this align with your Title attribute remark?
The "contains" search type ("like") is disabled on a specific subset of the User Attribute types including (but not limited to) "Title". This appears to be by design, but I cannot see that we document which attributes have this limitation. (There is an old open defect (unresolved) with engineering requesting clarification on this issue).
This occurs everywhere in the product and not just in the rule filter. It is most obvious from the search filter on the Users tab.
The system will try and autocomplete the choices for these string attributes if you choose the "=" value for these attributes. It appears the auto complete function only populates values in the drop down box if the number of values for the attribute is below a certain value. This may vary by system. In my lab the Title attribute does not auto complete the drop down list as I have thousands of Titles, but the Department attribute does auto complete the drop down list as I have only 7 Departments.
Is that answer sufficient or would you like a more detailed explanation from engineering as to why they use this design?
In addition a cautionary note should be made.
Relational operators such as "like" may resolve to SQL queries that are much less efficient than queries that use equalities. The actual performance impact may depend on the specific attribute and the size of your data but may be substantial. RSA does not guarantee that because a relational operator may be selected that it is always possible for it to be used in practice.
Thank you - I think I am good for now.
With the exception that the membership rules do not like "account" variables, only "users".
using an advanced query, you could very well use the accounts views and tables and hook them up to your user part of the membership rule via the account-user tables.
But then I would ask: what would make the accounts so interesting in your process? Roles are really user based as they should orient themselves on user tasks and organizational roles.
Or is it that you have some account attribute that you would like to utilize, more like lifting it up to, user level?
If those attributes are of more value, then why not collect them with another identity collector and make them user attribute values?
Retrieving data ...