[HOLD for payment 2024-11-01] [Improvement] Ensure New Expensify Supportal provides View access to all required information

[VictoriaExpensify]

Problem:

Currently, New Expensify Supportal is inconsistant with the information the support team member is able to view. All the information in the following locations looks good:

• Search
• Account Settings

The following information appears inconsistantly, or not at all:

• Inbox
• Workspace Set Up

Why is this important:
Without being able to view this information, the support team is essentially "flying blind" when a customer reaches out for support. This results in a poort customer experience as we cannot see what features the customer has enabled and we need to ask them to provide information that we should have access to.

Solution
Find an engineer to help us give View access to all parts of the customers account via New Supportal, with the exception of:

• Chat threads
• Virtual Card details

Issue Owner

Current Issue Owner: @VictoriaExpensify

[VictoriaExpensify]

Examples:

INBOX
** [email protected] - from within the account:**

From Supportal:

WORKSPACE SETUP
[email protected] - from within the account:
See this spreadsheet and the screenshots linked here

For additional context, all information contained within the customers account should be viewable via New Supportal. The only exceptions to that are:

• Chat threads
• Virtual Card details

[VictoriaExpensify]

Posted a P/S to #Whats_Next - https://expensify.slack.com/archives/CC7NECV4L/p1725349471929479?thread_ts=1724995999.639489&cid=CC7NECV4L

[VictoriaExpensify]

As discussed here, applying the Internal and Hot Picks labels

[melvin-bot]

Triggered auto assignment to @anmurali (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[VictoriaExpensify]

This needs to be managed internally as external teams are not able to make updates to Supportal.

Anu - removing your assignment, I'm happy to be the BZ assignee for this one.

[VictoriaExpensify]

Not overdue - will post in Engineering chat in the morning to see if we can find an Engineer

[melvin-bot]

Triggered auto assignment to @tylerkaraszewski (AutoAssignerNewDotQuality)

[muttmuure]

@VictoriaExpensify Tyler is working on higher priorities and can't get to this for a few weeks. Do you want to go ahead and post to #engineering-chat or WN and we'll see if we can get someone else?

[VictoriaExpensify]

Thanks @muttmuure - I've already posted this to Engineering Chat

[VictoriaExpensify]

Update Sept 11:
NewDotQuality auto-assigner assigned this to Tyler, but he is unable to work on this for a few weeks due to higher priorities. Posted to Engineering Chat, but no takers, so I'll keep working on finding an engineer.

I will start trying to recruit an engineer. If anyone in Conci knows an engineer who might be interested, please reach out to them (or me!)

[maddylewis]

@muttmuure / @puneetlath -- I want to make sure we (the newdot support team) are handling these issues correctly.

here puneet confirmed internal tooling issues should be added to NewDot-Quality project board [Medium] + the Hot Picks label after posting in WN / trying to recruit in eng-chat.

however, it sounds like going through that process didn't end up assigning someone who had the bandwidth. what is the best path forward in that scenario?

would it make sense for the engineer assigned to adjust the K2 label from daily to weekly but keep it assigned? or, could the eng assigned communicate they can't working on this atm and reapply the auto-assigner to get someone else assigned?

These internal tooling improvements are crucial to effectively supporting customers using New Dot, so I want to make sure we're all on the same page. so lmk your thoughts! :)

[muttmuure]

I was thinking more along the lines that if we can get someone else sooner, then we should. Typically an engineer will look at an issue and pick it up if it is unassigned. If it's assigned to someone already, most people assume it's going to be worked on soon.

We can reapply the label and ask the next person to work on it. That's OK too.

[thienlnam]

Still need to investigate why the accounting tab thinks it is loading - I see that it's making a call to the endpoint OpenPolicyAccountingPage which should be whitelisted, but it seems to fail immediately

[VictoriaExpensify]

Thanks for continuing to investigate this @thienlnam. Accounting integration issues are one of the items that we troubleshoot the most, so having this info available in Supportal is super important. Let me know if there is anything I can do to assist :)

[VictoriaExpensify]

Hey @thienlnam - any update on the issue with the accounting tab?

[thienlnam]

Okay after some debugging I figured out the fix:

Was odd because it would say that the request to OpenPolicyAccountingPage completed in 0ms with no response. I originally thought it was because it was put into the sequential queue and because we failed to re-authenticate we never actually end up sending the request to read the accounting data. However the other requests worked, so I was wondering if there was something different with the commands and indeed there is another place where we need to whitelist commands in App

https://github.com/Expensify/App/blob/e74eb8e705bce3e8791e3eb043fe5cbb1cbaecea/src/libs/Network/NetworkStore.ts#L100C1-L119C2

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.0.53-1 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• [No QA] Allow support authToken to call more commands #51303

If no regressions arise, payment will be issued on 2024-11-01. 🎊

[melvin-bot]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@thienlnam] The PR that introduced the bug has been identified. Link to the PR:
• [@thienlnam] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
• [@thienlnam] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
• [@thienlnam] Determine if we should create a regression test for this bug.
• [@thienlnam] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@VictoriaExpensify] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[VictoriaExpensify]

Oh, you're not a C+ @thienlnam ! 😆

This is all fixed and looking good:

Going ahead and closing this out (without payment, sorry Jack! haha)