Does anyone have a recommendation for how to make a list of what Generic Inquires use a specific table or specific field? This would be useful when Acumatica makes a change to a table (INSiteStatus) or field (AMReplenishmentSource) so we can quickly edit our GIs that would be affected. I know I can have a GI list all of our GIs, but not sure how to look deeper into them to get this information. Possible?
Generic Inquiry Table "Where Used"
+12
I think there is a table GITable which you should be able to join to GIDesign on DesignID.
Userlevel 7
+19
GIDesgin can store only the IDs, but not the table names.
Here is the screenshot for reference.
You can write a where condition to the ParentTable or ChildTable.
+12
GIDesgin can store only the IDs, but not the table names.
Hence joining to GITable.
Userlevel 3
+1
That’s excellent! I knew someone had to have tried this before. I’ll give it a go and let you know how I do.
Have a great week!
Userlevel 3
+1
The GIRelation works great for what I am looking for. But I found another oddity. Running 23R2. I’m trying to make a GI that would let me see all the important GI settings. I’ve noticed that the “Site Map Title” field does not show unless I have the GIDesign.DesignID field enabled and visible. And I also cannot get the GIDesign.Visible field to show. Just shows false for all GIs. Expose to Mobile works fine. In this screenshot the GIs with Expose to Mobile marked True should also show Make Visible on the UI as True. Is this a case of one of those “calculated on the fly” fields? I wouldn’t think so since this field is referenced when using Inspect Element.
+12
If you click on the GIDesign link in that screenshot, you’d be taken to the DAC Schema Browser where you would find this:
Userlevel 3
+1
I saw that. So how do I display what it is set to? From Sitemap?
+12
It appears that most of the sitemap-related fields are calculated from whether or not it appears in the site map. My best guess is that it searches the SiteMap.Url for the designID and grabs its values from SiteMap data.
Userlevel 7
Hi
Userlevel 3
+1
Hi
You know I never figured out a way to get the value of that setting. Not sure why there are actual settings for an entity that use calculated fields. I’m sure there is a reason, but it would seem that it would make sense to just make that a table field and be done with it. I’m able to see the sitemap information so that gets me most of the way there. It would be nice to just have all the settings related to a GI to make it easier to validate across so many records.
Userlevel 6
+2
You can check table that are holding your generic inquiry configuration if you click Export as XML and then investigate the file.
Here's the list of the tables:
- GIDesign
- GIFilter
- GIGroupBy
- GIMassUpdateField
- GINavigationParameter
- GINavigationScreen
- GIOn
- GIRecordDefault
- GIRelation
- GIResult
- GISort
- GITable
- GIWhere
- ListEntryPoint
- Sitemap
- MUIScreen
All "GI*" tables can be joined with GIDesign using DesignID field.
ListEntryPoint and Sitemap are connected via ScreenID. GIDesign can be joined with the Sitemap table using PrimaryScreenIDNew field (named PrimaryScreenID when inspecting element).
MUIScreen can be joined with with Sitemap using NodeID field.
Regarding Visible field - it's a speculation on my part, as I didn't see the code that works with it, but I'd say it's most likely is relying on many different table that can be changed anytime, so if you make it persistent field in the database you'd have to make a lot of check in different places just to keep it up-to-date.
It should account for Row Level Security feature, Access Rights configuration, Features enabled, etc. This list is too big to be able to guarantee that Visible value in the GIDesign shows the truth. Moreover, these settings are out of the scope of the generic inquiry - "GI*" tables explain how the screen is filled with data, but visibility configurations are applied the same way they do for regular screens.
So it's just a marker for your convenience so that you don't need to walk all over the places to make sure it's visible.
Userlevel 3
+1
What I don’t understand it that it is a setting for a GI that can be checked or unchecked in the GI Design form. To me that should be a field that is part of the GI definition. It should be handled the exact same way as the Expose to Mobile checkbox is. What difference am I missing with this? So what you’re saying is basically that value is held somewhere else in the database, and the field is just a convenient way to set it from this form?
Userlevel 6
+2
You can actually read the gist of what’s happening behind the scenes when you check/uncheck this field in the info:
I understand your comparison with the Expose to Mobile Application, and it does make sense from the user standpoint.
But Mobile Application uses the same Site Map, just with some additional checks, so it can be developed differently - Make Visible on the UI creates new records in the Site Map, while Expose to Mobile Application is just a flag that checks at the moment the app tries to gather all screens mobile user should be able to see.
It’s just two different approaches - one (mobile) is relying on the data generated by someone else and thus can be passive. The other has no other sources to use (without making the application incredibly slow) thus, it has to be proactive and generate data that will allow it to find pages.
Userlevel 3
+1
So if I wanted to “recreate” the calculation of this field in a GI, is there a specific thing to look for in the Sitemap, or would it be enough to look at the Screen ID that is generated? If there is a Screen ID populated, then I can infer that the “Make Visible on the UI” is checked?
Userlevel 6
+2
I’ve investigated the functionality a bit more, and from what I’ve gathered, it seems that the field shows if any Site Map record is associated with the GI.
However, it’s not just joining tables - it’s checking if any Site Map node is associated with the URL, constructed in real-time checking GIDesign.DesignID and GIDesign.Name
You can’t reproduce it in GI right away without additional tinkering - if you want identical representation, you’ll need to reverse engineer the calculation logic and create your own DAC that will have the field set in the same way (GIDesign.Visible is set in the graph, for your purposes I think it won’t suffice, you need it to be set on DAC level) and then join it with the GIDesign in your GI.
However, right now for me, it seems that for most cases just joining with Sitemap and checking that the record has been found would suffice - there’s a chance in some cases you will receive false positives, but I doubt this will be a frequent occurrence.
TL;DR - if you’re satisfied with 90%* precision - yes, just make left join with Sitemap and then check if the Sitemap record is found.
* number is purely a speculation, to show that most likely you won’t see the difference
Userlevel 3
+1
Yeah, that’s pretty much what I settled on doing to move forward. Thank you for digging deeper into this!
Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.