0

I did wrong and I promoted a non-security-review-ready version in a managed package.

I have a global identifier and if I try to create a new version without the it, it triggers a Global/WebService identifiers cannot be removed from managed application:. If I roll back to the global identifier I start getting the AvoidGlobalModifier;Avoid using global modifier violation. It is a severity level 3.

Could you please share what are my options to pass the security review for this violation?

Update 1 : When I requested a rollback in a Support Case I was redirected to Revert Second-Generation (2GP) Managed Package to Beta

and Use Branches in Second-Generation Managed Packaging

Then I manually added in my sfdx-project.json file:

  • 1st a package alias
  "packageAliases": {
    "[email protected]": "04t7R0000018v4SQAQ", // this is the released one
    "[email protected]": "04t7R0000018unhQAA", // this is the one that I target to be the parent
    "[email protected]": "04t7R0000018uncQAA",
  }
  • 2nd I added a dependency to my package definition:
      "path": "force-app",
      "default": true,
      "package": "myPackage",
      "versionName": "myPackage-4.1.0",
      "versionNumber": "4.1.0.NEXT",
      "branch": "rc3",
      "versionDescription": "myPackage",
      "dependencies": [
        {
          "package": "[email protected]"
        }]
    },

  • 3rd I ran the sf package version create
sf package version create -p "myPackage" -c -t="G4E-6527 at git commit afb6387" -b=G4E-6527 -x --post-install-script PostInstallScript --post-install-url "https://docs.glue42.com/connectors/salesforce-connector/installation-and-configuration/index.html#custom_metadata_types-visual_url" --verbose -a=myPackage-4.1.0.2-rc3  --skipancestorcheck
  • The Error are all about the same:
Warning: (1) MyCustomAction: Cannot modify managed object: entity=AuraDefinitionBundle, component=0Ab5t000000Xbgu, field=BundleType, state=installed
  • 4th I have updated my package definition once again:
      "path": "force-app",
      "default": true,
      "package": "myPackage",
      "ancestorVersion": "NONE",
      "versionName": "myPackage-4.1.0",
      "versionNumber": "4.1.0.NEXT",
      "branch": "rc3",
      "versionDescription": "myPackage"
    },

Update2: Now, I encounter the following errors in almost all of my Tests during package version creation:

System.QueryException: No such column 'External_Field_Name__c' on entity 'myNS__Mapping__c'. If you are attempting to use a custom field, be sure to append the '__c' after the custom field name. Please reference your WSDL or the describe call for the appropriate names.
13
  • 1
    Globals are permitted and indeed needed in managed packages if you need to expose a class or set of methods for use by subscribers. They are generally not required otherwise.
    – Phil W
    Sep 13, 2023 at 18:51
  • 2
    If you have not got the version introducing the global installed anywhere you can ask Salesforce Support to revert it back to beta then you can remove the global if you do not need it.
    – Phil W
    Sep 13, 2023 at 18:52
  • 1
    You really must use scratch orgs for 2GP development; this is what they are designed to support. There are some complexities (specifically around if you have dependencies you need to install) but scratch orgs can share the package's namespace. You have to have the config/project-scratch-def.json and sfdx-project.json files so package version creation can succeed, so you should adopt best practice. You can read around this over here. This is very detailed but will help with understanding.
    – Phil W
    Sep 19, 2023 at 12:00
  • 1
    2GP supports having an extra folder with metadata that supports unit testing but that is not part of the package. However, AFAIK, you are still expected to include the actual unit tests in the package itself.
    – Phil W
    Sep 27, 2023 at 6:04
  • 1
    I think you raised a new question for that, right? (Which is a good idea.)
    – Phil W
    Sep 28, 2023 at 14:32

1 Answer 1

4

If you're working on a 1GP, you simply need to:

  1. Ensure the version(s) of the package containing the spurious global modifiers are not installed anywhere,
  2. Raise a Salesforce Support case to ask for them to revert these version(s) to beta and
  3. Replace the global modifiers and create a replacement version of your package as desired.

With 2GP, you just need to abandon that version branch, creating a new version with an appropriate ancestor that omits this undesired change. Clearly, anyone with the abandoned version installed will be unable to upgrade since that version won't be an ancestor of any later development, but hopefully no one is using it. You'll find some more info around ancestry here.

9
  • Unfortunately support had answered that "The revert to beta process is used for making changes to published 1GP packages only." And they forwarded me to Revert Second-Generation (2GP) Managed Package to Beta help.salesforce.com/s/articleView?id=000381270&type=1. Which leads to another package of version creation errors.... I would see what else I could provide in Description related to my branching experience... Sep 19, 2023 at 7:45
  • 1
    With 2GP you should be able to simply dead-end that "bad" version and create a new one with an appropriate ancestor. I suggest you engage with the wider partner community for Managed Packages if you are struggling with that.
    – Phil W
    Sep 19, 2023 at 7:56
  • I have updated the details in the Description, Could you please elaborate on how to do the dead-end that "bad" version? Or you refer to creating a new package directly? Sep 19, 2023 at 9:02
  • 1
    I've updated my answer with some links to explanations around 2GP versioning, ancestry and version branching. Dead-ending is simply where you do not use the "bad" version as the ancestor of any other versions. I hope the linked documentation helps you understand this better.
    – Phil W
    Sep 19, 2023 at 9:36
  • 1
    That suggests you need to create a new version, without any ancestor, and deprecate the other one(s).
    – Phil W
    Sep 28, 2023 at 8:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .