using vscode to fix reports that break from configuration changes

changes to configuration, like updating picklist values, can easily mess up salesforce reports, which is a perennial problem for yours truly. i think sometime in the middle ages i dealt with this using eclipse but only vague memories remain.

working today on using vscode to deal with this…first I needed to get all reports locally.

this post on dev forum suggested a nifty package generator extension

I used that extension to generate the package. check the “report” metadata type and it crunched through all 6k(!) reports we have and created a package.xml file

packagexmlreports.png

then i could easily retrieve all reports by right clicking on the package.xml file and selecting “retreive source from org using manifest” in vscode!

retrievesource.png

i then used find/replace in folder to update the old picklist value to the new one! but if I then use force:source:push it deploys all reports, not just the modified ones.

I found a way to only deploy modified reports : use sfdx force:source:tracking:reset before doing the find/replace to on reports

per the multiple warnings thrown all over this command, THIS CAN BE DANGEROUS AND YOU SHOULD BE CAREFUL

this command ‘resets’ the source tracking so it doesnt see any changes (like all the reports we just pulled in). but in this case that is just what i want.

after running the command, do find/replace in the reports folder in vscode to replace the old value with the new value.

then run force:source:push and only the reports that were just modified will be pushed (bc we had reset source tracking)!

however, if any of the reports you modified have other errors (invalid picklist values, deleted record types, etc)…those will throw an error and nix your deployment…

pushError.png

but i simply copied those reports into .forceignore and did force:source:push again and SUCCESS!

successpush.png

you can copy/paste the errors from terminal in vscode into excel and split text to columns to get the report names. you also can get the errors in deployment status in the target org

format for forceignore is reportname.report-meta.xml (no folder name)

docs:https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_exclude_source.htm

so that gets the reports to a sandbox, but how do you get them to prod (without deploying all reports, or manually selecting them in a change set…)

you may be able to use force:source:push and set -username to your production org. i dont think that will run tests and the deployment will fail, but have not tested yet.

i was testing out the new devops center functionality, and that worked like a charm.

list of steps

 
2
Kudos
 
2
Kudos

Now read this

Single Sign On from Production to Sandbox

Make it oh-so-easy for users to test changes in a sandbox by seamlessly logging in from production! Summary: With this approach, your users can login to a sandbox directly from the app launcher in production. This requires no code, just... Continue →