none
Create a set with all objects having a non-empty attribute

    Question

  • Is it possible to create a set with all objects having a non-empty value for an attribute?

    If I try to leave the value field empty in the condition, I get a message saying "You must complete the definition of your filter before proceeding."

    I tried to use quotes, like in
    <attribute> is not ""
    but it does not seem to work, objects with an empty value for the attribute are still members of the set.

    Is there a way to accomplish this?

    Thanks,
    Paolo
    Thursday, June 04, 2009 2:20 PM

Answers

  • There’s a number of ways to approach “is present” and “is not present” however I’ve found a number of bugs in and around this area, and have had to work around sets based on such conditions almost completely.  So, while this works reasonably well for static-type sets, I’ve found you cannot use these sets for MPR scoping or state-change criteria.

    /Person[contains(attr, ‘*’)] and it’s inverse of /Person[not(contains(attr, ‘*’))] are unsupported in the current build and also don’t work properly.  In fact, the contains() clause in general has a number of bugs.  Likewise the more appropriate way, from the PG, is as follows:

    /Person[(attr != ‘$$$’)] and /Person[not(attr != ‘$$$’)] where the former gives you all people with a value (other than ‘$$$’) and the latter gives you all people without a value (or a value of ‘$$$’).  Again, while this appears to work initially you’ll find it doesn’t work properly when objects are supposed to transition out of these sets, i.e. when they then have a value.

    Furthermore, almost all clauses that utilise contains() seem to fail, and you require this when evaluating against multi-valued strings as far as I can see.  Run some tests and feedback against these bugs if you don’t mind?

    https://connect.microsoft.com/feedback/ViewFeedback.aspx?FeedbackID=462372&SiteID=433

    https://connect.microsoft.com/feedback/ViewFeedback.aspx?FeedbackID=462370&SiteID=433

    I’ve had success with reference attributes however, e.g. /Person[manager = /Person/manager]  and /Person[manager != /Person/manager].  I believe similar approaches can be utilised for non-reference attributes, e.g. /Person[DisplayName != /Person/DisplayName] but I haven’t had chance to test sets and multiple transitions yet.

    If you feel strongly about the need for a presence function, e.g. “IsPresent()” please add feedback to the above bugs to articulate this requirement to the very busy PG.

    • Marked as answer by Paolo Tedesco Thursday, June 11, 2009 7:48 AM
    Sunday, June 07, 2009 9:52 AM

All replies

  • I don't think you can do it directly in the FilterBuilder, but you can work around it.  The following example will create a set of all people whose job title is not blank.

    1. Create the following filter with the filter builder:

    Select people that match all of the following conditions: 
           Job Title  is not  junk

    If you view membership, it will give you all people who don't have a job title; and the filter will be:

    /Person[not(JobTitle = 'junk')]

    2. Finish & submit the Set creation.

    3. Go back and edit the Set; Click on Advanced View, and change the filter manually to:

    /Person[JobTitle != 'junk']

    4. Finish and submit the changes.

    Now, if you do an XPath query for /Set[DisplayName = 'Those with job title']/ComputedMember, you'll see all people who do have a job title (provided you don't actually have a job title named 'junk').

    Hope this helps,
    Joe
    Thursday, June 04, 2009 4:56 PM
  • Hi Joe,

    thanks for your answer.
    I tried your solution, but I don't manage to make it work; I'm using ILM2 RC0, maybe you are using a different configuration?

    Whatever I put in the set condition, I keep getting the objects that don't have the attribute set. I also tried setting in the advanced view /Person[DisplayName != ''] - from the advanced view it's possible, but still it does not work.

    The strange thing is that if run an enumeration using the web service interface (http://blogs.msdn.com/imex/), with a filter like /Person[DisplayName != ''], I correctly get only the users that have a display name.

    This looks like a bug in the sets management to me...

    Cheers,
    Paolo
    Friday, June 05, 2009 9:48 AM
  • Hi Paolo,

    How are you checking your Set membership?  If you're using the View Membership in the Dynamic tab of the Set definition, it won't work.  It seems like the portal is loading the xpath back into the filter before it runs the query.  You can define the filter as I mentioned, and then query the web service for /Set[DisplayName = 'Your Set Name']/ComputedMember, and it will correctly show you the members.  Also, if your filter works from the web service interface, then you've already verified your filter. 

    Just remember that you can't go back to the filter builder after you've set the xpath filter in the Advanced View.  And I agree, this is a bug.

    Joe
    Friday, June 05, 2009 3:50 PM
  • I find that the search scope is the best place to try out xpath filters
    David Lundell www.ilmBestPractices.com
    Sunday, June 07, 2009 2:17 AM
  • There’s a number of ways to approach “is present” and “is not present” however I’ve found a number of bugs in and around this area, and have had to work around sets based on such conditions almost completely.  So, while this works reasonably well for static-type sets, I’ve found you cannot use these sets for MPR scoping or state-change criteria.

    /Person[contains(attr, ‘*’)] and it’s inverse of /Person[not(contains(attr, ‘*’))] are unsupported in the current build and also don’t work properly.  In fact, the contains() clause in general has a number of bugs.  Likewise the more appropriate way, from the PG, is as follows:

    /Person[(attr != ‘$$$’)] and /Person[not(attr != ‘$$$’)] where the former gives you all people with a value (other than ‘$$$’) and the latter gives you all people without a value (or a value of ‘$$$’).  Again, while this appears to work initially you’ll find it doesn’t work properly when objects are supposed to transition out of these sets, i.e. when they then have a value.

    Furthermore, almost all clauses that utilise contains() seem to fail, and you require this when evaluating against multi-valued strings as far as I can see.  Run some tests and feedback against these bugs if you don’t mind?

    https://connect.microsoft.com/feedback/ViewFeedback.aspx?FeedbackID=462372&SiteID=433

    https://connect.microsoft.com/feedback/ViewFeedback.aspx?FeedbackID=462370&SiteID=433

    I’ve had success with reference attributes however, e.g. /Person[manager = /Person/manager]  and /Person[manager != /Person/manager].  I believe similar approaches can be utilised for non-reference attributes, e.g. /Person[DisplayName != /Person/DisplayName] but I haven’t had chance to test sets and multiple transitions yet.

    If you feel strongly about the need for a presence function, e.g. “IsPresent()” please add feedback to the above bugs to articulate this requirement to the very busy PG.

    • Marked as answer by Paolo Tedesco Thursday, June 11, 2009 7:48 AM
    Sunday, June 07, 2009 9:52 AM
  • Joe, David,
    thanks for your advice. It looks like there's a problem with 'View Membership' in the portal, and 'search scope' and direct queries to the web service are indeed the best way to verify how xpath filters work.


    Paul,
    actually I wasn't thinking about multi-valued attributes in particular, here.

    Anyway, I've noticed this strange beahvior with sets: is this what you meant with "it doesn’t work properly when objects are supposed to transition out of these sets
    "?
    I defined two sets
    "All users with display name": /Person[DisplayName!='']
    "All users without display name": /Person[not(DisplayName!='')]
    If I look at sets membership, it seems to work correctly.
    Then I defined a MPR that triggers a workflow on the transition from "display name" to "no display name"; this worked fine on the first transition, i.e. when I assigned the users a display name.
    Now, if I try to remove the 'display name' property from a user, that user disappears from both sets (and therefore future transitions from one set to another are not possible any more).

    I added the above to the first bug link, and alos stated that it would be very useful to have a simple way to create filters for objects with a non-empty value for a certain attribute.

    By the way, what's the point of having /Person[DisplayName!='$$$'] rather than simply /Person[DisplayName!=''] ?


    Thanks,
    Paolo
    Monday, June 08, 2009 9:07 AM
  • I know this is an old thread, but does anyone know how to find empty values for attributes that have a data type of Datetime?

    Basically, i want to find all accounts that do or do not have a value.


    Opper ...don't stop.
    Tuesday, June 21, 2011 12:51 PM
  • Try this:

    /Person[not(EmployeeEndDate > '2001-01-01T00:00:00')]

    Good luck!

    Joe

    Tuesday, June 21, 2011 3:15 PM
  • Hi guys,

    4 years later, I have exactly the same problem.

    The links to the bugs on connect.microsoft.com are not valid anymore.

    I am using FIM 2010 R2. Do you know if there has been any improvement (i.e. bug correction) in this release? Is it safe now to modify the filter of the set through the "Advanced View" tab?

    Matthieu

    Wednesday, June 10, 2015 9:32 AM