function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
nimbusprojectnimbusproject 

How do you check 'Allow Reports' value

I was wondering how to do the following:

 

I need to find all sObject types that have the 'Allow Reports' flag check to be true

The 'Allow Reports' flag is in 'Optional Features' when creating a custom sObject

 

I basically just need to know how to find this value for all the sObjects in the Schema or know how to find all sObject types with this set to true. 

mtbclimbermtbclimber
You can't access this information from Apex. You may be able to through the Metadata API, however. What's the use case?
nimbusprojectnimbusproject

I have currently done the following to get all of the sObject types in the Schema.

 

public List<String> sObjectLabels{get;set;}

/* Get Map of sObject names mapped to sObject Types */
Map<String, Schema.SObjectType> gd = Schema.getGlobalDescribe();

sObjectLabels = new List<String>();
              
for(String obj_name : gd.keySet())
{       
     sObjectLabels.add(obj_name);
}
 
But I would like to have a way to filter out the list of sObjects by doing something like this in the  for loop
 
for(String obj_name : gd.keySet())
{       
     // Need to have function to do sObjectType.getAllowReports()
     // Where getAllowReports is not a function currently defined
     if( gd.get(obj_name).getAllowReports() == true ) {
          sObjectLabels.add(obj_name);
     }
}
 
 If there is a way to take an sObjectType and check whether it allows reports or not to be done on it I would love to know.
 
Thanks,
Jason 
 
 
 
 


mtbclimbermtbclimber
Right I know *what* you want to do. "What's the use case?" is my way of asking *why* you want to do this.
 
As I've been discussing on other threads recently, there is no API for reports so I'm curious what you want to do with the resulting list or why you want to exclude objects that aren't enabled for reports from whatever it is you are doing/planning to do. 
 
If, for example, you are trying to prevent the user from selecting an object that can't be used in a SOQL query (presumably when driven by dynamic soql) then you are going down the wrong path as that is indicated by isQueryable() on the respective Describe Result. 


nimbusprojectnimbusproject
We basically what I am trying to do is build my own custom reporting tool that allows use of selecting multiple object types. This will then produce something similar to the current reporting tool where once you pick the sObject types you want to report on (For example Account and Contact) it will produce a list of related fields.
 
I currently have everything working except for the part relating to the 'Allow Reports'
The very first page loads a list (statically) of sObjects that all have checkboxes next to them to select which ones to use in the Report.
I need this list to be dynamic so that if a user adds a new custom sObject type and checks 'Allow Reports' to have it set to true then this sObject will show up on this list for the first page of my custom reporting tool.
 
Basically I just need to have a list of Strings that contains the names of the sObject types that are able to be reported on.
I will see what the list produces when using this isQueryable()


mtbclimbermtbclimber
Ok. That makes sense, you are basically wanting to hook into the standard metadata for objects to give the admin a mechanism to limit what is shown in the list to his/her end users.   
 
All custom objects are queryable that check is to simply allow you to prevent a query from hitting an exception.
 
So adding an isReportable flag would be helpful for your particular use case. I would certainly expect that to be provided in the context of a more significant reporting API feature but I'm not sure it would come in absence of that. You are welcome to log an idea for that though. If you do your last post describes what you are trying to accomplish pretty well.
 
For now your best bet may be to leverage custom settings to store the list of objects to present for selection.  This may be better in some respects anyway since the admin may want different values or the ability to delegate to his/her end users (see the hierarchical custom settings type). 
 
Thanks,