• Andy Fawcett
  • NEWBIE
  • 85 Points
  • Member since 2012
  • CTO
  • FinancialForce.com


Badges

  • Chatter
    Feed
  • 0
    Best Answers
  • 0
    Likes Received
  • 1
    Likes Given
  • 0
    Questions
  • 11
    Replies
We've successfully added a number of Custom Fields using the Metadata API.  Our site is an Asp.net and we're using VB for coding (thought about posting to .NET Development, but our question is more API focused).  First we build a Custom Field: 
metaCustomField = New sfMetadata.CustomField
metaCustomField.fullName = "Account.TestField__c"
metaCustomField.description = "Test Field for Account"
metaCustomField.inlineHelpText = "Test Field for Account"
metaCustomField.label = "Field Label"
metaCustomField.length = 20
metaCustomField.lengthSpecified = True
metaCustomField.unique = False
Then we add the Custom Field to an Array of Custom Fields (metaCustomFields).  There are roughly 40 fields, so we limit the array to 10 and submit each batch of 10 fields using:
metaCustomFieldsResult = myMetaService.create(metaCustomFields)
This all works well, and the fields are created as desired.  The first time we created the fields, it worked perfectly and we were then able to use the Soap API to populate the Account object with data (including the custom fields).

However, for some reason, if we delete a Custom Field and then add it again, or if we test using other Salesforce logins, the fields are getting generated properly, but the permissions on the fields are no longer being set (none of the "Field-Level Security" is set to visible).  We're not sure what we changed, but we've begun looking into how to apply Permission Sets to the Custom Fields for the Account object.  There appears to be a couple concepts to consider.  First, we've seen some code for building a package.xml file listing our field permissions and then submitting the zipfile:
<fieldPermissions>
     <editable>true</editable>
     <readable>true</readable>
     <field>Account.TestField__c</field>
</fieldPermissions>
In addition, we noticed that there are some additional Metadata API functions that look like they might help, but we can't find any details or code samples on how to apply them:
' Will adding either of these lines to the
' Custom field definition help:
metaCustomField.visibleLines = 1
metaCustomField.writeRequiresMasterRead = True

' Or, define a Permission Set
metaFieldPermission = New sfMetadata.PermissionSet
' Not sure what to do with it from here...

Can anyone tell us if we are heading in the right direction, or if there is a preferred method for setting the "Visible" Field-Level Security permissions for the custom fields we have created?

  • May 23, 2014
  • Like
  • 0
Last week, it was brought to my attention that security reviews and audits are now asking ISVs to check for Field Level Security (FLS) and Object CRUD permissions prior to any DML outside of standard controllers.  

This is a fairly radical change that impacts a lot of managed package applications across the board. I and others have several concerns about this change in the security review process:
  1. Why the sudden change in security review policy?  
    • None of the ISVs I have talked to were informed of the change prior to being either audited or submitting any apps for security review.  The only official documentation I can find on the change is a blurb in the Security Scanner help page here: http://security.force.com/security/tools/forcecom/scannerhelp.  
    • As ISVs, it would be greatly appreciated to have an official Security Review Guide, that is updated well in advance to when policy changes like this take place.  Some ISVs have several packages, others lots of customizations, and we all need time to prepare for the security review.
  2. Has the security scanner been updated to enforce this rule yet?
    1. I have not run an app through the Security Review process recently, so I am curious if this rule has been implemented already in the security scanner. (http://security.force.com/security/tools/forcecom/scanner)
  3. Why force FLS and CRUD checks on every DML transaction?
    • I am a fan of using standard controllers when necessary, but several apps, including one my company develops rely heavily on Custom Controllers.  In most cases where FLS comes into play, typically it's a simple fix of a profile permission or permission set that resolves the issue.  Instead, now, we have to implement FLS and CRUD checking prior to each DML transaction.  This adds complexity on top of existing DML calls.  
    • If need be, can the FLS and CRUD checking be done on a one-time run in an install script?
    • Does Salesforce have any plans of either adding FLS checking for custom controllers or adding methods to Apex for checking credentials similar to the Force.com EASPI library? (https://code.google.com/p/force-dot-com-esapi/)
Thanks, I look forward to hearing any feedback on this issue.

For our use case we need to be able create Custom Objects (metadata) on the fly, possibly copied from a template object then modified.

 

How would I go about this, and are there any examples out there?

 

I've already seen this other thread:

http://boards.developerforce.com/t5/Apex-Code-Development/Is-it-possible-to-call-Metadata-API-from-Apex-code-Getting-Error/td-p/119412

 

I haven't been able to implement this though.   I've exported the WSDL, converted it to apex, and put it into a class via the Force IDE.  The class saves/compiles, but I've been unable to actually write any apex using it to do anything, as I can't find any examples and I am not clear on what the syntax should be (though from the end of the thread it appears they were not successful either?).

 

Has anyone done this successfully?  I actually see that there has been a related contest put up at http://blogs.developerforce.com/developer-relations/2012/01/developer-content-contest-2-metadata-api.html but I need to figure out if what I need is possible quickly since whether/how we use salesforce hinges on this

  • February 09, 2012
  • Like
  • 0

Hi

 

 

I have a webservices class and I generate a class from wsdl and now I need to write test class for it but here there are no methods in it and only having  variables and classes, here I wrote test class creating an object for each class and Inner class also but not covered it showing 0%.

 

 

can any one help in this plz

 

 

thanks

SRS

Hi All,

 

I am new to Saleforce development. Please can any one guide me to sample apex code to create(add) custom fields to custom or standard objects dynamically using Salesforce Metadata API in my development org.

 

Thanks in advance.

  • June 29, 2011
  • Like
  • 0
Last week, it was brought to my attention that security reviews and audits are now asking ISVs to check for Field Level Security (FLS) and Object CRUD permissions prior to any DML outside of standard controllers.  

This is a fairly radical change that impacts a lot of managed package applications across the board. I and others have several concerns about this change in the security review process:
  1. Why the sudden change in security review policy?  
    • None of the ISVs I have talked to were informed of the change prior to being either audited or submitting any apps for security review.  The only official documentation I can find on the change is a blurb in the Security Scanner help page here: http://security.force.com/security/tools/forcecom/scannerhelp.  
    • As ISVs, it would be greatly appreciated to have an official Security Review Guide, that is updated well in advance to when policy changes like this take place.  Some ISVs have several packages, others lots of customizations, and we all need time to prepare for the security review.
  2. Has the security scanner been updated to enforce this rule yet?
    1. I have not run an app through the Security Review process recently, so I am curious if this rule has been implemented already in the security scanner. (http://security.force.com/security/tools/forcecom/scanner)
  3. Why force FLS and CRUD checks on every DML transaction?
    • I am a fan of using standard controllers when necessary, but several apps, including one my company develops rely heavily on Custom Controllers.  In most cases where FLS comes into play, typically it's a simple fix of a profile permission or permission set that resolves the issue.  Instead, now, we have to implement FLS and CRUD checking prior to each DML transaction.  This adds complexity on top of existing DML calls.  
    • If need be, can the FLS and CRUD checking be done on a one-time run in an install script?
    • Does Salesforce have any plans of either adding FLS checking for custom controllers or adding methods to Apex for checking credentials similar to the Force.com EASPI library? (https://code.google.com/p/force-dot-com-esapi/)
Thanks, I look forward to hearing any feedback on this issue.