forcedotcom / forcedotcom/cli

force:source:retrieve on top level produces different source than when run on subdirectories

Open
#424 3 comments 0 reactions 0 assignees View on GitHub
area:auth owned by another team
Dominant language
No language data
Stars
571
Forks
80
Avg merge
2d 15h
Merged PRs (30d)
3

Description

### Summary

Working on a Gen-1 Manage Package, specifically with permission sets, the source content depends on how it's retrieved from the Org.

Running `force:source:retrieve` with `--sourcepath` pointing to the top level project (`force-app/main/default`) produces slightly different source than if run on a sub-directory (`force-app/main/default/permissionsets`). Both sets of source are functionally equivalent, but the first version produces source with "extra" permission definitions whereas the second version produces a cleaner set of source with just the settings originally specified in the permission sets.

### Steps To Reproduce:

**Repository to reproduce:** [dreamhouse-lwc](https://github.com/dreamhouseapp/dreamhouse-lwc)

> Should I have forked that repo? The steps below are sufficient to reproduce this issue, but I can fork and push what I did to reproduce (just step 1).

1. Create copy of `dreamhouse.permissionset-meta.xml` and remove all settings for `Property__c` (delete lines 204-219, 191-199, 50-181, 7-14)
1. Push new permission set to the Org
1. Run `sfdx force:source:retrieve --sourcepath ".\force-app\main\default\permissionsets"`, note the contents of the new permission set go unchanged.
1. Run `sfdx force:source:retrieve --sourcepath ".\force-app\main\default"`, note the contents of the new permission set are updated with all the implicit settings for `Property__c`, which were originally unspecified.

### Expected result

Source managed by SFDX doesn't depend on how it's retrieved from the Org.

### Actual result

Source depends on how it's retrieved from the Org.

### Additional information

> Note: We're working a blended a workflow between Gen 2 and Gen 1. Our Managed Package is Gen 1, but we're trying to transition to developing in Scratch Orgs and then sync to our Gen 1 Dev Org for the release process.

**SFDX CLI Version**(to find the version of the CLI engine run sfdx --version):

sfdx-cli/7.58.2-937f666ed4 win32-x64 node-v10.15.3

**SFDX plugin Version**(to find the version of the CLI plugin run sfdx plugins --core)

@oclif/plugin-autocomplete 0.1.5 (core)
@oclif/plugin-commands 1.2.3 (core)
@oclif/plugin-help 2.2.3 (core)
@oclif/plugin-not-found 1.2.3 (core)
@oclif/plugin-plugins 1.7.9 (core)
@oclif/plugin-update 1.3.9 (core)
@oclif/plugin-warn-if-update-available 1.7.0 (core)
@oclif/plugin-which 1.0.3 (core)
@salesforce/sfdx-diff 0.0.6
@salesforce/sfdx-trust 3.0.7 (core)
analytics 1.7.1 (core)
generator 1.1.2 (core)
salesforcedx 48.14.3 (core)
├─ @salesforce/sfdx-plugin-lwc-test 0.1.5 (core)
├─ salesforcedx-templates 48.17.0 (core)
└─ salesforce-alm 48.15.0 (core)

sfdx-cli 7.58.2 (core)
shane-sfdx-plugins 4.28.2

**OS and version**:

Windows 10 Pro Version 1909 (OS Build 18363.836)

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.