Some populated columns display as if empty.

[simes1]

I've found FetchXRMBuilder displays certain columns as if they have no value even when (using a filter) it is clear that they do contain a value.

For example these owner columns are empty:

But the filter says the owneridtype is a team (as I'd expect):

In addition you can only select these columns with the Friendly Names setting off. If you turn it on it looks like this:

I'm not sure if that's related or if I'm doing something wrong...

-- Simon

---

• Deployment: Online
• DB Version: 9.2.21082.132
• Connection Controls Version: 1.2021.6.44
• XrmToolBox Version: 1.2021.6.51
• Tool Version: 1.2021.4.4

[rappen]

Thanks @simes1, I will investigate!

[rappen]

Looking at metadata, it says info about the ownerid* attributes, they are fishy. These attributes can't be used for filter (except the FetchXML does not fail) and the "data" is not set on these attribute, I really don't know when the info is available....

Any more info?

[MarkMpn]

I found that these virtual attributes aren’t handled in the same way as normal physical attributes in all sorts of ways.

To get the values, the type and name values can be extracted from the EntityReference value in the physical attribute. I’m not sure about the yominame value.

To filter on these attributes you need to add a join to the appropriate other table(s), e.g. to find records owned by a team you can add an inner join to the team entity rather than a filler on the owneridtype attribute.

[rappen]

This setting is "safe", where this weird attributes are hidden 😉

[simes1]

Apologies, I've perhaps not used the best example... There are many other ways one can check if a row is owned by a user or a team and I couldn't remember the specific column(s) I was looking for at the time I had this problem when I was submitting this. However, these common owner fields seemed to operate the same way. I'll try to remember what the original ones were.

@rappen I think the filter clause does actually work (rather than simply not error) - if I select the expected value in the filter condition those rows are returned, if I select that it is empty those rows aren't returned. I'm using options that superficially look the same as yours but with them I can easily display one of these columns:

@MarkMpn I'm not actually creating FetchXML queries as such I'm using FetchXML builder just to inspect and analyse data because it's so much quicker and has fewer restrictions than Advanced Find. I've used PowerQuery as well but I like to be able to easily switch between friendly names and more easily see the option set labels, lookup values etc.

What's so confusing is that it's so easy to add one of these columns to the view and then think it must be empty - rather harder and less obvious to add it to the filter and find that actually it appears to have values in it...

[simes1]

I think this is one of the ones I was looking at - Accepting User Or Queue Object Type/acceptingentitytypecode on email:

Unlike the owner ones you can use it in advanced find:

From memory there was something similar for the regarding lookup on a mailbox.

[MarkMpn]

This is the same type of attribute as the others you were looking at around ownerid - this is another virtual attribute that isn't valid to include in the results directly.

So the question is how best to make this less confusing? The main options I can see are:

1. Always exclude virtual entities from the list in the attribute editor
2. Change the default options to include the "Only valid for read" option
3. Change the grid display to extract the name/type values from the EntityReference values

Any opinion @rappen?

[simes1]

Well obviously I'd prefer 3 because it would make it so much easier to then use those attributes/columns in any filter. Perhaps they would need some warning sign next to the column name though so it's clear you couldn't use them in a real view?

On a related note it would also be useful to be able to see the various isvalidfor* metadata when selecting columns to add to the view (but possibly not when choosing them from drop-downs because of the space?).

[rappen]

1. I want to see this dialog have a few checkboxes where you show which attributes. Easily "Read Only", but also a bunch of various metadata options. Now it only shows name and type, could also (optional) more meta info.

2. Alse some info from you fetch with "attributes for reading", showing basic like logicname, displayname, entity, and also "all" metadata options. Same thing too for "attributes for filter" and the same info. So you open a fetch-info, with all data about it...

3. From any Attributes node property or Condition node, it should have a quick to open attribute meta details.

What you think?

[rappen]

I haven't heard any more, so the added three new issues will make it at least better :) Closing now.

[simes1]

Sorry I've not had time to look at this again and I didn't completely understand what you'd said.

However, using the latest release just now, I think the changes you have made so far are indeed a big improvement.

I'd still like (somehow) to be able to see the values in those special attributes because constructing filter conditions using them would be so much easier if you could do this. The confusing combo of IsValidForRead, IsValidForGrid, IsRetrieveable IsValidForAdvancedFind (and maybe others?) doesn't make it at all clear why a columns is blank. One thinks they really do have no value when actually (I've so far found...) that they usually do have an underlying value and you can actually could filter on them if you did but know that.

[rappen]

I agree. Will try to find the best way of showing this info.

First, my columns here show wrong metadata... 🙄

Has now Read, Create, Update, Custom. Would be a lot better with Read, InGrid, Retrieve, InAdvFind at least...

Also some "warning" is the treeview and/or the Node Properties too.

This is good idea, started a bit too fast, I will open it again.

[rappen]

What do you think of this?

[rappen]

I'm cleaning out my closet...

Three years later, do you have any thoughts about what you would most like to get in FXB regarding this issue, @simes1?

[simes1]

It's too long ago, (and I've not used FXB for a while), but my memory was that you fixed quite a bit of this. I'd close for the moment - if I remember/revisit I'll reopen/post again.