3
We know we could retrieve everything, parse it, insert the attribute and deploy, but that's a lot of work.
This option may not be a lot less work, but the open source build tool my team owns (CumulusCI) includes a framework we call "Metadata ETL" for automating exactly this type of change.
Metadata ETL tasks extract a specified subset of metadata ...
2
It turns out it was the BulkMacrosAllowed user permission.
I removed the following from my Admin.profile-meta.xml file.
<userPermissions>
<enabled>true</enabled>
<name>BulkMacrosAllowed</name>
</userPermissions>
It does raise the question of how we are supposed to do these name to label translations, but that is ...
2
Per your comment:
that custom object is managed. And that managed package is paid. And it is not installed on my developer edition ( where I am deploying ) and I don't want to install that 3rd party manage package in my developer edition
That won't work. You must refer to this custom object using its fully-qualified API name, including the namespace prefix ...
2
Yes, fundamentally, that's the start of the process for moving from Developer Edition-based development to scratch org-based development. Either (1) or (2) works fine; they're basically equivalent so it comes down to what you find easier (I generally find 2 easier).
Once you've pulled down the metadata you need (and converted it to Salesforce DX format), you'...
2
There's no real magic to it. You must create all of the other metadata changes that you expect to have happen.
For Layouts, you'd have to pull the existing Layout metadata, make changes to it to add your new field in the desired position, and then redeploy it. You can do this using the Apex Metadata API, if desired, or use the Tooling or Metadata APIs.
For ...
1
A closer look at the XML file makes the problem apparent:
There is an empty line / blank space before the XML prolog. Clearing out everything before the <xml version... resolved the somewhat cryptic error message.
1
You're following outdated examples. The Picklist Metadata API type and corresponding field on CustomField were supported until API 37.0.
In later API versions, you must instead use the valueSet property and the ValueSet type.
The fact that you're getting those errors suggests your Metadata API classes were generated from a WSDL that postdates API 37.0, so ...
1
I found one possible solution posted by SteveMo in API Names of System and App Permissions?.
I can use the field describe metadata from PermissionSet to map from the fields Name to its label.
Images from Steve's post.
I've posted an expanded set of mappings in Mappings between Salesforce Permission Name and the Label
1
The reason why the describeMetadata is so "small" is that there's a lot of types that are grouped together, such as Settings. To complete the list, call listMetadata for each type that has subcategories. For example, listMetadata(Settings) will get AccountSettings, IdeaSettings, etc. For example, in Salesforce DX:
sfdx force:mdapi:listmetadata -u ...
1
Did a quick test on my DEV org and tried to add a translation to packaged custom label with the amazing Apex Wrapper Salesforce Metadata API.
Adding a namespace to custom label name worked for me:
MetadataService.CustomLabelTranslation clt =
new MetadataService.CustomLabelTranslation();
clt.label = 'Some text';
// replace namespace prefix below with ...
1
Package based approach is easier since the handcrafting package XML can be error-prone.
You can run the command sfdx force:source:retrieve -n MyPackageName to retrieve everything in your package in DX Source format without having to go through unzipping of file or conversion from one format to another. Here MyPackageName is the package name, you will need to ...
Only top voted, non community-wiki answers of a minimum length are eligible
