[MPDX-8973 MPDX-8974 MPDX-8981 MPDX-8982 MPDX-8987 MPDX-8988] - PGA Report Update

[wjames111]

Description

This PR is for updating the PGA report to function as the 12-Month Donation Summary Report. The full scope of work is available here.
I'm doing most of the work in this PR but splitting out the print functionality into a separate one as that will introduce a good amount of complexity.
Here are the following tickets that this PR addresses:

• MPDX-8973 Include Print Button
• MPDX-8974 Directly Show Donations Tab in Contact Panel
• MPDX-8981 Staff Account Balance card (Total Donations for this Period will be added in a separate PR
• MPDX-8982 Creates query for getting getting Staff Account Balance
• MPDX-8987 Add preselected filters
• MPDX-8988 additional Field to PGA Report (no longer including donor id)
• MPDX-9030 Add “toal donations for this period” to front-end
• MPDX-9028 Add pledge_frequency to commitment amount

Checklist:

• I have given my PR a title with the format "MPDX-(JIRA#) (summary sentence max 80 chars)"
• I have applied the appropriate labels. (Add the label "On Staging" to get the branch automatically merged into staging.)
• I have requested a review from another person on the project

[github-actions]

Bundle sizes [mpdx-react]

Compared against 88bb693

Route	Size (gzipped)	Diff
/accountLists/[accountListId]/reports/partnerGivingAnalysis/[[...contactId]]	289.51 KB	+2.22 KB

[github-actions]

Preview branch generated at https://MPDX-8988-additional-pga-fields.d3dytjb8adxkk5.amplifyapp.com

[canac]

This looks really good! I guess you're still working on making printing print all pages? And are you still working on adding the donor ID?

You grouped a lot of tickets into this PR. That's OK since they're small, but I would have also been OK with multiple tiny PRs. They're fast to test and approve.

Is it OK for this PR to merge into production since we don't have a production SAA server yet? No production users will have a staff account. So we might want to hide comment out the skeleton for now. Also, is Scott OK with these changes going live as soon as they are approved? Or does he want to do UAT first?

[canac]

I see now in the ticket that you said you're no longer adding the donor id to the report. Can you update the Jira ticket to reflect that?

[canac]

One more minor comment. The code looked great while I was testing it!

[wjames111]

@canac, let me check with Scott on merging this to production. The BalanceCard should only show for those with a staff account

     {!staffAccountLoading && staffAccountData?.staffAccount?.id ? (
            <BalanceCard />
          ) : null}

Let me know if you want me to break these up. That was my plan initially but after realizing how small some of these tasks were I decided to just put it all in one PR.

[canac]

The BalanceCard should only show for those with a staff account

@wjames111 Correct, but won't the skeleton show temporarily while loading and then disappear and cause layout shift since no production users have staff accounts yet?

[canac]

Basically there, so I'll approve. Thanks for all of the improvements! Before merging, make sure to test that the double-scrolling is gone, and let's have a plan for the loading skeleton (I'm thinking we comment it out, but we can discuss).

[wjames111]

@canac I'm having trouble recreating the double scrolling issue. I do see two scrollbars one for the page and one for the table, is this what you are talking about? If so do you know of a good fix? I could make the BalanceCard smaller but then it wouldn't be uniform to the other reports or I could reduce the size of the table but then that makes reading it a little more difficult.

[canac]

I do see two scrollbars one for the page and one for the table, is this what you are talking about?

Yeah, that's it. I see what you're saying about keeping the same card. That balance card takes up a lot of vertical screen real estate though. It also makes it so that you have to scroll the page to the bottom of the table then scroll the table to get to the pagination controls.

Is it a requirement that we use the same balance card? If not, put we put that information inline with the search bar (just a quick mockup, the padding and layout is a little off)?

As a user, I think I'd rather see a shorter balance card so that I can see more rows of the table. As a user, I personally don't care that much about the primary account balance because I probably just saw it on the dashboard page before navigating to the PGA report. So I would want it to be unobtrusive. In the current layout on my large laptop, the table only gets half of the vertical space. I'm not familiar with any requirements discussions though, these are just my own personal thoughts. If you want feedback from someone on the UX team, feel free to ping Ryan to see if he has ideas (not required though).

If we need to use the same budget card, then we should probably remove height: 'calc(100vh - 240px)', from Table.tsx to remove the double-scrolling.

On an unrelated note, I see the "total donation for this period" requirement in MPDX-8981? Where is that implemented?

[wjames111]

I do see two scrollbars one for the page and one for the table, is this what you are talking about?

Yeah, that's it. I see what you're saying about keeping the same card. That balance card takes up a lot of vertical screen real estate though. It also makes it so that you have to scroll the page to the bottom of the table then scroll the table to get to the pagination controls.

Is it a requirement that we use the same balance card? If not, put we put that information inline with the search bar (just a quick mockup, the padding and layout is a little off)?

As a user, I think I'd rather see a shorter balance card so that I can see more rows of the table. As a user, I personally don't care that much about the primary account balance because I probably just saw it on the dashboard page before navigating to the PGA report. So I would want it to be unobtrusive. In the current layout on my large laptop, the table only gets half of the vertical space. I'm not familiar with any requirements discussions though, these are just my own personal thoughts. If you want feedback from someone on the UX team, feel free to ping Ryan to see if he has ideas (not required though).

If we need to use the same budget card, then we should probably remove height: 'calc(100vh - 240px)', from Table.tsx to remove the double-scrolling.

On an unrelated note, I see the "total donation for this period" requirement in MPDX-8981? Where is that implemented?

So the use of the current balanceCard was suggested by Joanna, I don't believe it was a requirement though, so I think we could probably do your inline suggestion. I forgot "total donation for this period" needs to be added to the card as well. This might cost us some space too, let me play around with the card and see if I can get something that fits.