0

Title says it all.

I recently uninstalled a managed packaged that had a custom trigger(s) reference it. The trigger is not part of the managed package.

Now that the managed package is gone I cannot access the triggers, either directly in the web browser or by downloading the Prod Environment into an IDE but they are still counting against code coverage.

My question is what's the best way to delete these triggers from the Prod environment? Because of them the code coverage is below 75% so I believe my options are limited.

  1. This is not a free managed package so in order to re-install I'd have to reach out to the company and ask them to grant me a trial or something so I get the schema back into Prod and can delete the triggers permanently.
  2. Write test classes around sObjects that don't exist and deploy to Prod (is this even possible)?
  3. Reach directly out to SFDC support and ask for help though we are a small company and so Developer support is handled through the community forum so not sure what they'd offer to do here.

If anyone has experienced something like this before or can dig up a similar instance I'd be very grateful.

Unmanaged Triggers Referencing Uninstalled Managed Schema Unmanaged Triggers Reference Uninstalled Managed Schema with No Coverage

Trying to Access a Trigger in Production Trying to Access a Trigger in Prod

Viewing the Trigger in a Sandbox Copy Trigger Viewed in a Sandbox

5
  • 1
    I don't think we can uninstall the package if there are custom component referring it. We first need to remove the reference. Commented Oct 3, 2017 at 6:59
  • 1. Your last screenshot shows "delete" button, any luck with clicking that? 2. Anything promising when accessing via Developr Console? 3. Alternatively do you know how to craft "destructivechanges.xml" and deploy it from Eclipse, Workbench etc?
    – eyescream
    Commented Oct 3, 2017 at 7:02
  • 1
    Managed package coverage does not count against your org coverage. Your trigger seems to not be part of a managed package and you could not have uninstalled it if it did. You maybe looking in the wrong place or interpreting the data wrong because what you are implying should not be possible
    – Eric
    Commented Oct 3, 2017 at 7:13
  • @Eyescream - the final screenshot is from a sandbox so deleting there won't help the issue in Production. I'm not familiar with descructivechanges.xml, do you think it will help in this instance.
    – j.sweet
    Commented Oct 3, 2017 at 16:17
  • @Eric - Agreed it shouldn't be possible, but do you have an alternative explanation. The managed package is factually uninstalled now and I can find this trigger in a sandbox and it's clearly referencing a managed sObject from the package.
    – j.sweet
    Commented Oct 3, 2017 at 16:20

1 Answer 1

0

Digging around a little more I found this thread - Apex Code Coverage: Test classes are included with 0% in overall code coverage calculation

The top answer solved my issue as well. So it seems these triggers were deleted along with the managed package, but the coverage data needed to be recalculated (not sure why when I selected run all tests alone it didn't solve this).

3
  • Glad you found that but it is important to understand that even if coverage data is included for managed packages it DOES NOT count against overall org coverage. So if your overall coverage is low is IS NOT due to the managed packages. Although I am curious if you found a bug where since the package is no longer installed it is treating it like they are no longer managed classes...hmmmm
    – Eric
    Commented Oct 3, 2017 at 18:31
  • @Eric, sorry if I wasn't clear up front. These triggers were never managed, they only referenced components in a managed package.
    – j.sweet
    Commented Oct 3, 2017 at 22:00
  • You should not have been able to uninstall if they still referenced the package. Shocked it let you do it
    – Eric
    Commented Oct 3, 2017 at 22:07

You must log in to answer this question.

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