In this question, Jeremy mentioned that it's possible to pass complete report criteria by passing in the pc0, pn0, and pv0 parameters, corresponding to the object's field id, filter operator, and filter value. I've tried this out, but since field IDs can vary among Salesforce environments, I can't figure out a way to encode the pc0 values in a way that can be safely deployed across environments. Is there a way to do this?
-
possible duplicate of Custom New Button that creates record of specific type and parent record in Visualforce Controller (No URLFOR!) You might be successful with some screen-scraping utility that'd visit setup pages and write findings to a List custom setting... Horrible "solution".– eyescreamCommented Jun 3, 2013 at 20:09
-
I don't see how this is a duplicate. There may be similar approaches that could be applied, but that assumes a particular solution to this problem. These are different use cases, different parts of the Salesforce app, and there may be different approaches to solving the problem.– BenjCommented Jun 4, 2013 at 18:12
-
For me the root problem is "how to obtain & safely store field Ids" that can be then used in all kind of URL-hacking activities. And until we have a way of learning that (Metadata API doesn't have such capabilities, maybe the new Tooling API...) - we need to obtain them somehow through scraping of either standard forms or setup pages... I think that starting Summer custom settings will be copied to dev sandboxes during refresh so that might be a way.– eyescreamCommented Jun 4, 2013 at 18:35
-
@eyescream the metadata api can do it :), I've used it a bunch for generate CSVs with a list of fields which includes the field ID (which is nice for creating links to the field from the sheet) as well as the created by and last modified by id which are absent from the standard retrieve metadata call.– Ralph CallawayCommented Jun 4, 2013 at 23:42
Add a comment
|
1 Answer
It's not exactly a solution, but you can take advantage of the fact that sandboxes use the same IDs for fields. Create the field in production and then create a new sandbox. You'll then be able to reference the id for the field in the sandbox without worrying that it'll break once it's deployed. This assumes that you'll need to dynamically pass in the field to the report.
If however, you don't need to dynamically pass in the field to the report, just the filter parameter, just setup the report so it already has the field in place for the first filter and leave the filter value blank. Then you'll only need to pass in the value to the report and you avoid the whole ID issue in the first place.
Of course, if you're willing to go the extra mile, you could use the List call of the metadata api to get the IDs of the Fields programmatically. Then you need to post deploy update the IDs with the correct values for the field you're working with. You can do this with ANT or the Metadata API.
Some example list output from ANT
************************************************************
FileName: objects/Custom_Object__c.object
FullName/Id: Custom_Object__c.Field1__c/00N50000001zXXXXEAU
Manageable State: unmanaged
Namespace Prefix: null
Created By (Name/Id): Joe Blow/00550000000XXXXAAI
Last Modified By (Name/Id): Joe Blow/00550000000XXXXAAI
************************************************************
************************************************************
FileName: objects/Custom_Object__c.object
FullName/Id: Custom_Object__c.Field2__c/00N50000001zYYYYEAU
Manageable State: unmanaged
Namespace Prefix: null
Created By (Name/Id): Joe Blow/00550000000XXXXAAI
Last Modified By (Name/Id): Joe Blow/00550000000XXXXAAI
************************************************************
The Metadata API returns a FilePropertiesResult which includes the same data as above.
answered Jun 4, 2013 at 13:10
-
Great ideas, but I don't think it'll work for me. Sadly, not all sandboxes of the same environment. And we already use the trick of pre-setting some fields, but have some reports where we want to choose the fields dynamically as well. We may end up just making several copies of the report.– BenjCommented Jun 4, 2013 at 17:34
-
Does Metadata include the field IDs? I've never seen that in the resulting XML before.– BenjCommented Jun 4, 2013 at 17:35
-
1Not in a retrieve call but in a list call. At least with ant it returns to a text file, updating the answer with links to list call docs and example output from ant. Commented Jun 4, 2013 at 23:34
-
HOLY SHEEET. Awesome :) I wish I could upvote twice. Still means we need to hack around if we want this info in Apex but at least it's not screenscraping of setup pages or "new" standard page layout. But pls fix the link, I think it should be salesforce.com/us/developer/docs/api_meta/Content/…? Commented Jun 5, 2013 at 7:30
-
Weird, they've been fixed Stackexchange did some extra helper encoding that broke the earlier links. I'd clicked the open in navigation link so when people click it they have the full contents next to the page. Commented Jun 5, 2013 at 16:29