Home Blog Displaying Attributes of a Related Object

Displaying Attributes of a Related Object

Brian Stevens | September 30, 2021

One of the great features of the Acumatica XRP Platform is that it eliminates the need for a lot of custom coding via Attributes. For example, the Stock Items screen provides attributes according to the item class of the item; the Vendor screen provides attributes based on the vendor class; and the list goes on and on.  What makes this feature so incredible is that the system administrator can set up a list of attributes to be maintained according to the classification of the item, vendor, etc.  While these attributes could be values that have no placeholder in the system yet, they also may vary from class to class.

The Acumatica XRP Platform holds many screen and code examples that can be copied to add attributes to custom screens.  However, what if the goal is to display the attributes from ANOTHER screen… from a related object?  Fear not.  The process is quite easy for a developer and can be broken down into 3 easy steps as I illustrate below.

To set the stage, a business requirement has been received to display various tabs of data related to an item from the Stock Items screen, so the attribute tab on the custom screen will look to InventoryItem for attributes.  Since this is intended to be defined for visibility rather than maintenance, be sure to lock down access to maintain the attributes tab via permissions or code.  (Disclaimer: This 2021 R1 code has not been tested for maintaining the related attributes!)

Step 1Create a custom version of CRAttributeList

GISThttps://gist.github.com/BrianMRO/6e442e41e0dcaa748f6efceb8c67aeed

This code may look complicated to new developers, but it really isn’t.  Most of the important code is in redefining SelectDelegate so that we retrieve the related object and fetch its attributes.  The bulk of this section is because we must copy the constructor and all the internal and private methods and variables from CRAttributeList to make them accessible since their protection level makes them inaccessible through inheritance.  Remember, technically inheritance lets them be inherited, but that does not mean they are accessible to you in your new class.

Taking a closer look at SelectDelegate, the current MyDAC record is retrieved from the cache, and then the related InventoryItem record referenced in MyDAC is retrieved.  Passing the InventoryItem object (item) into SelectInternal will allow the rest of the attribute to function normally but based on the related InventoryItem rather than the MyDAC record of the custom screen.

Step 2 Define the Answers view for the Attributes tab

GISThttps://gist.github.com/BrianMRO/4e78a158f7dce459395c6b5710d95a06

This mirrors the use of CRAttributeList for obvious reasons.  The custom attribute is based on CRAttributeList, and the name basically is the only thing that changes here from any other screen.

Step 3 Add the Attributes tab

GISThttps://gist.github.com/BrianMRO/ae4e7bb280477faa80a54c7b3bce6e46

This .aspx code can be copied from almost any screen that contains an attributes tab.  It simply looks to the Answers view to populate the standard grid.

After compiling, updating the customization project with the new DLL, and publishing the project, the new Attributes tab should display the attributes of the related object from within the custom screen.

Happy Coding!

Brian Stevens

Brian is the lead developer for SETECH Supply Chain Solutions, LLC. SETECH provides tailored solutions based on best practices to improve the availability of indirect materials while reducing the total cost of ownership for their clients.

Categories: Developers

Subscribe to our bi-weekly newsletter