Add Address Column to PXSeelctor for Contacts, Leads & opportunities

I’m guessing ‘Leif’ is also your username:

Or<BAccount.bAccountID, Equal<Current<AccessInfo.userName>>,

BAccountID is an int. UserName is a string.

Hello @Leif 

On top of the fix from @darylbowman, if you want to modify the selector columns for every Contact, Lead or Opportunities selector on the site, you can do so in a CacheExtension for each of these DACs. Doing it this way will modify the selector columns for every selector of the DAC on the site, so you don’t have to add CacheAttached to each GraphExtension you want the modification to apply to. Here’s an example just modifying the ContactID selector to add AddressLine1 from Address using a new unbound field on the Contact CacheExtension.

using PX.Data;
using PX.Objects.CR;
using System;

namespace CD
{
    public sealed class ContactExt : PXCacheExtension<Contact>
    {
        public static bool IsActive() => true;

        public abstract class addressLine1 : PX.Data.BQL.BqlString.Field<addressLine1> { }
         PXString(50, IsUnicode = true)]
         PXUIField(DisplayName = "Address Line 1", Visibility = PXUIVisibility.Invisible)]
         PXFormula(typeof(Selector<Contact.defAddressID, Address.addressLine1>))]
        public String AddressLine1 { get; set; }

         PXMergeAttributes(Method = MergeMethod.Merge)]
         PXCustomizeSelectorColumns(
                typeof(Contact.displayName),
                typeof(Contact.eMail),
                typeof(ContactExt.addressLine1),
                typeof(Contact.phone1),
                typeof(Contact.ownerID),
                typeof(Contact.contactType)

            )]
        public Int32? ContactID { get; set; }
    }
}

Note we do not add a new abstract class for the ContactID field since it’s modifying a field from the base DAC, while we do add an abstract class for addressLine1 since it’s a new unbound field added in this CacheExtension. Another thing to note, having this functionality in a CacheExtension that is always active can negatively affect performance, specifically if you have a lot of unbound fields and you’re relying on querying Contact records for larger GI’s or other long running operations. In most cases you won’t notice the performance hit, it is just something to keep in mind. 

@darylbowman Yes I think you are correct. I tried to translate what I found in the original PXSeelctor Attribute.

From ContactSelectorAttribute function GetQuery, can you help me on translating this to FluentBQL?

Type type = BqlCommand.Compose(typeof(Where<,,>), typeof(BAccount.bAccountID), typeof(IsNull), typeof(Or<>), typeof(Match<,>), typeof(BAccount), typeof(Current<>), typeof(AccessInfo.userName));

Sorry, I got nothing there. Maybe give Nick’s suggestion a shot.

@NicholasBova52 

I like the ideal of adding the unbound field and using the PXFormula attribute. 

I worry about the performance hit, but it sounds like I shouldn’t be.

Yeah I only bring up the potential performance hit as something to be aware of, especially since it is emphasized within our developer documentation. If you implement your solution and performance is fine in testing then I otherwise wouldn’t worry about it!

Hi @Leif 

Type type = BqlCommand.Compose(typeof(Where<,,>), typeof(BAccount.bAccountID), typeof(IsNull), typeof(Or<>), typeof(Match<,>), typeof(BAccount), typeof(Current<>), typeof(AccessInfo.userName));

translates to

.Where<BAccount.bAccountID.IsNull
    .Or<Match<BAccount, Current<AccessInfo.userName>>>>

@andriitkachenko I see my mistake now, thanks for the fix