Updates based on functionality missing from forceappclean

[Nickers3]

Add xml files previously deleted in forceappclean branch

Critical Changes

Changes

Update Admin Profile with default page layouts Add contact validation rules Add QA org json file

Issues Closed

[Nickers3]

Hi!

Starting a new branch to have a fresh start on my end. Adding the post of changes you mentioned on forcecleanup. I'll respond in line below on the topics

• Looks like the Theme and Branding did not upload at all. I assume that's a known issue. Not sure why this is, the steps showed as it deployed @davidmreed any ideas?

• Email button wasn't on Case page layout. But shows up after Email to Salesforce is enabled. So not a problem, just noting that it has that required activation step. Email button shows on my case layout. I had added Email to Salesforce to the scratch org definition file, however noticed there isn't one for QA. Added that json file for us. Try a new scratch org and see if it works this time

• Contact page layout has "Notes and Attachments" related list. (Instead of the Notes and the Files lists, which I know I had placed there. This makes me think there is more about the layout that is changed, so I'll have to look into that.) Added OCC Page Layouts to the Admin profile in the unmanaged and it now shows notes and files. One thing to mention is the page layout assignment would need to be done as a post install step for orgs as the process I setup only works for scratch orgs.

• Account page layout has Notes and Attachments related list and Partners (?) related list. AHA! Both of those issues above are because the page layout assignment isn't set to the OCC layouts. And that probably also has something to do with having not deployed a profile. Hmm...this is something we'll need to noodle a bit. Yup, you're onto something there. Added OCC Page Layouts to the Admin profile in the unmanaged and it now shows notes and files. Some comment about manual post install goes here too.

-Contacts don't seem to be related to their Sailors. Neither the Sailor field nor the Relationship to Sailor field are filled on any that I'm looking through. I think that used to work in my old branch. On the latest run I did, the records were linked so not sure why it didn't work you.

-Anonymous Households were inserted (or contacts inserted then moved out). I think I had fixed that also in my branch, but not sure. Looking at the mapping file, the contacts are imported before the accounts. I think if we switch the order this would solve it. Haven't made this update yet as I want to do this alongside you.

It does not look like the OCC Lightning record page for Contact made it into the scratch org. (Only the NPSP one is there.) I can't find the OCC Contact Lightning anywhere in the old branches so I think it'll be best to start from new.

There is a Lightning Record Page for Account, but I'm not sure if it's ours or something else. (It's just named Account Record Page, which may or may not be the name I would have used...) My guess is this is the standard Account record page that got updated and pulled back. I think this would be another to delete and start a new. I'm thinking we do the Stand for Case too. Let's discuss

-I see only one Contact validation rule. My recollection is that I had more, but I'll have to check. Had thought the others were NPSP validation rules so I added them back in.

• Contact compact layout only assigned for default, not down to the record type This one I want to check with @davidmreed on. Looks like Compact Layouts are stored in an object file. Is it safe to include the Contact.object-meta.xml file in packages?

[mkolodner]

OK, just checked and there are no custom Lighting Record Pages for Contact or Account. So nothing missing there. (Sorry.) I get how the insertion order of Contacts and Accounts would be the cause. I'm happy to work with you on how to fix this. (I understand the theory, but messing with the mapping file and the created database seems risky...) I'm going to work on getting a scratch org going to compare.

[Nickers3]

The Lightning pages show in a different section: https://github.com/SFDO-Community-Sprints/OmbudsmanCloudCare/tree/forceappcleanup/force-app/main/default/flexipages

There is an Account and NPSP Contact page. I'd recommend we create an OCC Account and OCC Contact page so it is unique to the app. That's what we did with OBF.

[mkolodner]

Agree! (While we're at it, I should probably make those pages slightly more fancy, too. But I'm trying to avoid any changes that would impact packaging until we get the baseline established.)

[Nickers3]

Feel free to create those OCC pages. They'll be good to have within the base package.

[Nickers3]

One thing to mention is once they are installed via a package, the user need to update so having a firm baseline is good.

[davidmreed]

Compact Layouts are packageable as such, but I don't know offhand if you can package a Compact Layout on a standard object (I would guess not, but I may be wrong).

Themes and Branding, I have almost no experience with. Are you handling them unpackaged? I'm not sure whether or not they are packageable; the ISVforce Guide does not cover them.

[mkolodner]

Just tried twice to spin up a scratch org from this branch but it errors: `20-06-02 14:30:18: Beginning task: SFDXOrgTask 2020-06-02 14:30:18: 2020-06-02 14:30:18: Running command: sfdx force:source:push -u test-0qshfkz6ipnd@example.com 2020-06-02 14:30:20: Job ID | 0Af3F000010TcNVSA0 2020-06-02 14:30:51: TYPE PROJECT PATH PROBLEM 2020-06-02 14:30:51: ───── ───────────────────────────────────────────────────────────────────── ─────────────────────────────────────────────────────────────────────────────────── 2020-06-02 14:30:51: Error force-app/main/default/applications/Ombudsman_Cloud_Care.app-meta.xml NPSP_Contact_Record_Page does not exist or is not a valid override for action View. 2020-06-02 14:30:52: Return code: 1 stderr: ERROR running force:source:push: Push failed.

2020-06-02 14:30:52: Exception in task deploy_unmanaged.dx_push

Error: Return code: 1 stderr: ERROR running force:source:push: Push failed.

Run this command for more information about debugging errors: cci error --help`

[coriobriensfdo]

@mkolodner @Nickers3 FYI on Compact Layouts. We have issues with them https://powerofus.force.com/s/article/EDA-compact-layouts

[Nickers3]

@mkolodner the latest commit I did should resolve that error. Had made a change when talking lightning and forgot to make the change elsewhere in the repo.

[Nickers3]

@coriobriensfdo great info on the compact layouts. @mkolodner this seems like an important thing for the wiki so people don't overwrite only to get it reverted back to the package on update.

[mkolodner]

Good to know, @coriobriensfdo . I take it this means that if we package a compact layout we'll also cause the same thing when we have updates? Given that we're going to have a lot of post-install steps, we may just need to put all compact layout work as post-install. (Sigh. Less and less feels like it's actually going to be part of installation...)

[Nickers3]

@mkolodner we could keep the compact layouts in there. The main thing I understand is admins can edit in their org so the best practice is to clone vs. updating a packaged compact layout. Could use the link Cori shared for documentation for users.

On this topic, I don't see many of your users changing compact layouts so it may not be a super big issue.

[coriobriensfdo]

@mkolodner welcome to packaging ;)

It means that you can include a Compact layout if you want, however if a Customer edits it, they lose all of their changes each time it's upgraded which they find confusing and gets super annoying. So you can include one if you advise them never to edit it, but you'll probably give them a better user experience if you leave it out and advise them on how you'd recommend they configure it. But if you don't think they will ever NEED to customize it, then it'll be ok. It's one of the types of choices that can bite you later as the package grows and expands unfortunately. That's what happened with NPSP and EDA.

[mkolodner]

OK, exploring the Lightning Record Pages. Looks like the scratch org I just spun up from this branch does not have the NPSP Contact Record Page in it. That page, however, does exist in the scratch org I spun up from the last branch I had created (Log a Call on Case), where it is active and the app default. Shouldn't that have gotten there on its own based on the NPSP dependency? I can obviously create an OCC Lightning Record Page that we deploy. (And probably want to do that for several objects.) But it seems odd that the NPSP one isn't there in the first place...

On Account, there IS Lightning Record Page (named "Account") and already active as the App Default.

[mkolodner]

If I make a few changes (like that Contact Lightning page) and pull those down via retrieve_changes, it looks like I'm going to pull down extra stuff that you've intentionally pulled out of this repo (profiles, some org settings). How do I avoid those? (If this is too involved to answer here, we can cover it on Thursday when we talk, since it's fundamentally my question of how to continue development once your packaging work is successful.)

[Nickers3]

@mkolodner I had deleted the NPSP Contact Record Page from the repo thinking it was a part of NPSP. Looking at the NPSP repo, there is no NPSP Contact page so that makes me think it was either included in the trial org or was named NPSP. @coriobriensfdo or @davidmreed does that seem correct?

For the account, it would be good to rename that to OCC Account Record Page. I've seen a lot of orgs with Account Record Page so naming it OCC Account Record Page would help identify it as the OCC one.

[Nickers3]

On the pull back, you can use the .forceignore file. I think you can do fancy things such as exclude anything with NPSP. Sometimes things will still pull down and I choose to discard the changes. I can show you how I do that tomorrow on our call.

[mkolodner]

Yes--I'm going to need to learn how the development process works once things are packaged up. As for the LEX pages: 1. Yes, I agree adding "OCC" would be the way to go. Plus eventually there will be a namespace, too. 2. As for the contact page, I probably didn't realize that I had edited the NPSP page rather than creating a new one. (And the trial org vs. what's in the repo adds even more confusion!) We'll probably want to make an "OCC Contact Lightning Record Page" as well. And just to be safe: our call is Thursday, which is the day after tomorrow. (I know this week has already been nuts.)