sfdx package version create removes fieldPermissions from Profiles too aggressively

[amtrack]

Summary

We have some CustomFields on Activity.

• force-app/main/default/objects/Activity/fields/Event_Field__c.field-meta.xml
• force-app/main/default/objects/Activity/fields/Task_Field__c.field-meta.xml

However the field permissions for CustomFields of Activity in Profiles are stored on Event or Task:

Dummy Profile.profile-meta.xml

    <fieldPermissions>
        <editable>true</editable>
        <field>Event.Event_Field__c</field>
        <readable>true</readable>
    </fieldPermissions>
    <fieldPermissions>
        <editable>true</editable>
        <field>Event.Task_Field__c</field>
        <readable>true</readable>
    </fieldPermissions>
    <fieldPermissions>
        <editable>true</editable>
        <field>Task.Event_Field__c</field>
        <readable>true</readable>
    </fieldPermissions>
    <fieldPermissions>
        <editable>true</editable>
        <field>Task.Task_Field__c</field>
        <readable>true</readable>
    </fieldPermissions>

These fieldPermissions are being deleted when creating a package version because sfdx can't find the metadata in the project.

Extracted from ~/.sf/sf.log when using SF_LOG_LEVEL="debug":

The profile "Dummy Profile" from the "/path/to/project/force-app/main/default/profiles/Dummy Profile.profile-meta.xml" directory was added to this package version.
  The "Event.Event_Field__c" profile setting was removed from the "Dummy Profile" profile.
  The "Task.Task_Field__c" profile setting was removed from the "Dummy Profile" profile.

Steps To Reproduce

https://github.com/mdapi-issues/mre-2gp-profile-filtering

Expected result

The <fieldPermissions> should not be removed in this case.
The implementation in https://github.com/forcedotcom/packaging/blob/main/src/package/packageProfileApi.ts should be aware of the Activity/Event/Task model.

Actual result

The <fieldPermissions> are being removed incorrectly.

System Information

{
  "cliVersion": "sfdx-cli/7.207.5",
  "architecture": "darwin-x64",
  "nodeVersion": "node-v18.12.1",
  "osVersion": "Darwin 22.5.0",
  "shell": "zsh",
  "rootPath": "/Users/redacted/.config/yarn/global/node_modules/sfdx-cli",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 2.3.0 (core)",
    "@oclif/plugin-commands 2.2.16 (core)",
    "@oclif/plugin-help 5.2.10 (core)",
    "@oclif/plugin-not-found 2.3.26 (core)",
    "@oclif/plugin-plugins 3.1.3 (core)",
    "@oclif/plugin-search 0.0.17 (core)",
    "@oclif/plugin-update 3.1.19 (core)",
    "@oclif/plugin-version 1.3.5 (core)",
    "@oclif/plugin-warn-if-update-available 2.0.39 (core)",
    "@oclif/plugin-which 2.2.22 (core)",
    "apex 2.3.3 (core)",
    "auth 2.8.2 (core)",
    "community 2.3.2 (core)",
    "custom-metadata 2.1.26 (core)",
    "data 2.3.26 (core)",
    "deploy-retrieve 1.13.3 (core)",
    "info 2.6.22 (core)",
    "limits 2.3.22 (core)",
    "org 2.9.14 (core)",
    "packaging 1.20.0 (core)",
    "schema 2.3.14 (core)",
    "settings 1.4.14 (core)",
    "signups 1.4.22 (core)",
    "source 2.10.19 (core)",
    "telemetry 2.2.1 (core)",
    "templates 55.4.22 (core)",
    "trust 2.4.22 (core)",
    "user 2.3.17 (core)",
    "sfdx-cli 7.207.5 (core)"
  ]
}

Additional information

[github-actions]

Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support.

[mshanemc]

@amtrack that's an excellent repro, thank you.

[git2gus]

This issue has been linked to a new work item: W-13753544

[WillieRuemmele]

Hi @amtrack - I've been testing Shane's changes out with your provided repo and everything is looking great. This turned into a larger change than we had initially thought and I was hoping you might help us test it on some more complex package setups.

Can you can install the fixed plugin by running sf plugins install @salesforce/plugin-packaging@profiles and running through some packaging scenarios, especially the package version create command

you can verify the installation matches by comparing the sf plugins command to

 ➜  sf plugins            
packaging 1.21.5-profiles.1 (profiles)

and once you're done testing, you can run sf plugins uninstall packaging, or you can keep the fixed version installed until this is released

[amtrack]

@WillieRuemmele I just tried with the packaging 1.21.5-profiles.1 (profiles) version.

I don't see any more logs regarding Activity/Event/Task so it looks promising 👍 !

In my reproduction repo, creating a package version succeeds and I can spot the following log lines:

The profile "Dummy Profile" from the "/path/to/project/force-app/main/default/profiles/Dummy Profile.profile-meta.xml" directory was added to this package version.
  The "custom" profile setting was removed from the "Dummy Profile" profile.
  The "userLicense" profile setting was removed from the "Dummy Profile" profile.
  The "userPermissions" profile setting was removed from the "Dummy Profile" profile.

I can also confirm that changing includeUserLicenses to true keeps the userLicense correctly.

For our real package I could see that our 2 applicationVisibilities were removed from all our profiles in our real package:

The "applicationVisibilities" profile setting was removed from the "REDACTED Profile" profile.

--> I found a small bug on the PR forcedotcom/packaging#348 and proposed a fix: Application -> CustomApplication

[WillieRuemmele]

Thanks for looking into this @amtrack - I saw those new log lines using your repro as well, and that's because the CLI is now stripping them out, before sending them to the server. But according to these docs we found https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_dev2gp_profiles.htm, the server removes them as well

Could you elaborate more on

I can also confirm that changing includeUserLicenses to true keeps the userLicense correctly.

Is that a bug in the the proposed changes? Where did you change includeUserLicenses?

[amtrack]

@WillieRuemmele OK, thanks for the explanation.

Could you elaborate more on

I can also confirm that changing includeUserLicenses to true keeps the userLicense correctly.

Is that a bug in the the proposed changes? Where did you change includeUserLicenses?

Sorry I meant includeProfileUserLicenses instead of includeUserLicenses which is part of sfdx-project.json and documented in the link you sent me.

I just wanted to confirm that this config still works correctly after your refactoring :-). So there is nothing to act on.