Update ‘Command Contacted’ Field Not Populating via package

SFDO-Community / OmbudsmanCloudCare

App for Navy ombudsmen to track, resolve, and report on cases.

BSD 3-Clause "New" or "Revised" License

10 stars 5 forks source link

Update ‘Command Contacted’ Field Not Populating via package #60

Closed Nickers3 closed 4 years ago

Nickers3 commented 4 years ago

When running Send Case to Command Action, Command Contacted is not getting populated on package.

When a new field updates is created, it works so it may be due to the name space.

Nickers3 commented 4 years ago

Tried with new package and rebuilding the component within the packaging org and this time it worked.

Nickers3 commented 4 years ago

@mkolodner I created a user for you on the new packaging org if you wanted to take a look.

mkolodner commented 4 years ago

I concur that it worked. There seem to be other weird things about that org, though. When I created a test contact I had to manually create an account for him to be on--didn't work the NPSP way. But I confirm that once I got a Case actually created, in this org the Send Case to Command action worked as expected.

coriobriensfdo commented 4 years ago

@mkolodner the NPSP jobs are scheduled when the user first clicks on the NPSP settings tab. That shouldn't affect how a trigger works, but there's loads of stuff that happens the first time you click on the settings tab. Maybe do that and try again?

mkolodner commented 4 years ago

Interesting. I'm out of that org and I know Nick is working on other things. But is there something that ensures that a new org ends up with everything properly initialized? We're assuming OCC installations will start from an NPSP trial that turns into a P10. I suppose there's a chance a new admin setting up that org would never got to the NPSP settings tab...

coriobriensfdo commented 4 years ago

@mkolodner let me ask internally and see what else happens when the NPSP Settings are accessed for the first time. We may need to add "Click on NPSP Settings" as a required post-install just to make sure. I know the jobs are scheduled then.

Nickers3 commented 4 years ago

Glad to know the new workflow worked. I wonder if it's the order of when I create the namespace, upload via ci_master, link the namespace to the package and upload the beta package. If one of these is done out of order, things don't work right. Just a thought, not sure if I've done it differently or not.

For the org I'm in, I didn't really touch the NPSP Settings or profiles so that could be why things weren't working as expected. Wanted to do a "quick" test without doing all of the steps.

coriobriensfdo commented 4 years ago

@mkolodner @Nickers3 Here's what I got:

When NPSP Settings loads, we run a method called onNpspSettingsLoad() in STG_SettingsManager_CTRL. it handles:

inserting / resetting TDTM
cancels some super old npsp jobs that new orgs wouldn’t have anyway
if a default GAU is set, verifies if it’s valid (if not, it clears it and adds an error)
cleans up record types — i think this had something to do with custom settings storing names vs. ids from an older version?
and sets/resets the scheduled jobs (if not set and if the customer does not have the setting checked off to NOT reschedule them).

https://github.com/SalesforceFoundation/NPSP/blob/3bd16bc7ba73d72e95aa548a0ca810198eb7d715/src/classes/STG_SettingsManager_CTRL.cls#L77-L92

The Install Script: https://github.com/SalesforceFoundation/NPSP/blob/3bd16bc7ba73d72e95aa548a0ca810198eb7d715/src/classes/STG_InstallScript.cls

Nickers3 commented 4 years ago

@mkolodner, the initial issue has been resolved. Think it was user error on my order of uploading. Is there anything else to track with the NPSP settings? Otherwise, I'll close.

mkolodner commented 4 years ago

Close away!