Function WrapXPathFilter generates XML in different order about mimwal HOT 5 CLOSED

Hi @Jared632, not sure what you are trying to achieve by doing text comparison against an xml fragment, but you should be able to compare only the text of real interest (i.e. the actual filter element text) using RegexMatch function and that would be the way forward for you.

from mimwal.

I'm closing this issue as Won't Fix as doing text comparison against an xml fragment is a losing battle. If I look at the out of box sets, e.g. All Active People set, it has the same order as WAL. So if there is a needed, you'd have a better success rate doing text comparison of actual filter xpath (and even then the comparison would be meaningless if you have and/or such clauses as order is immaterial in XPath, but obviously text comparison would fail)

from mimwal.

@Jared632

I have seen this behavior in the Set XPath Filter and the Workflow XOML. I actually do comparisons with BeyondCompare and their XML Tidy Sorted/Ordered custom file formats. Works very well for MIM.

from mimwal.

I am noticing this same behavior for the Filter attribute on Group objects. However I'm not trying to compare Filters from different Groups or Sets for any reason. It is a much bigger issue for me.

When a normal user without permissions to modify the Filter attribute opens up a Group with Filter value supplied by this function in a workflow, if they change something like DisplayName and view the Members tab (manager based group), the summary page shows that they are updating the Filter attribute. The user is then prevented from being able to successfully complete their change as they receive permission denied modifying the Filter attribute.

It appears that when a user changes some other attribute and views the Members tab, the page re-writes the Filter attribute with the XML switched like the original poster mentions. Issue doesn't happen if only changing an attribute and NOT viewing the Members tab. Also doesn't happen with no other change and still viewing the Members tab.

I do understand that the original FIM Service code might write the Filter XML differently in Sets or Groups. It should order the XML namespaces consistently each time which may not be happening.

However, wouldn't it make more sense to update the string in the function to support Group objects vs Sets as in majority of the cases, Sets are viewed by Admins who are able to update the Filter attribute if this same situation were to happen?

Hopefully I've explained the situation thoroughly enough. If not feel free to ask for more information. I'd like to avoid having to compile my own version of the WAL for a client to correct this problem.

from mimwal.

Given backward compatibility concerns, you could make a copy of the existing function, call it "WrapXPathFilter2", make the edits and send a pull request. So whenever a next version is released, it will have this new function.

from mimwal.