[HOLD for payment 2023-09-21] [Wave 6: Categories] CRITICAL - Create Category MenuItem and CategoryPicker component

[puneetlath]

Tracking Issue: https://github.com/Expensify/Expensify/issues/282161

Design Doc: https://docs.google.com/document/d/1itXKWlhms5YHcF4-lujO6g8T5LPdLVD_7onjtZBsATQ/edit#

HOLD ON https://github.com/Expensify/Expensify/issues/302028

---

(Context) Fetching and Storing Categories

Even though the categoryObjects map is part of the policy object, we'll store them under a new collection key in Onyx: policyCategories_<policyID>. This has a few benefits over storing them directly in the policy. For instance, it allows categories to be evicted independently of the policy they belong to and makes it easier to update categories via Pusher.

Thus, we'll push category Onyx updates to all the members of the policy whenever changes are made by an admin in the policy editor. This will ensure clients have the most up-to-date copy of their policies' categoryObjects maps without having to fetch the full list each time they need to display categories.

With #vip-reliable-updates, we'll rely on GetMissingOnyxUpdates to keep the list up to date if you were offline when the changes were made.

Category Menu Item

We will build off of what will be added for the Date and Merchant fields in Wave 4: Scan Receipt.
Note: If this is not implemented yet, refer to the Wave 4 doc to implement the Category field before the Date and Merchant fields cc @MariaHCD

When creating a Money Request on a policy that has categories, we'll show a "Category" menu item that is initially empty:

We'll show the category as part of the MoneyRequestConfirmationList, as a MenuItemWithTopDescription, similar to what we presently do for the "amount" and "description" fields.

With the Distance Requests project, we'll start connecting to the workspace policyID in the MoneyRequestConfirm component. We'll only show the menu item if there's a policyID. Additionally, we'll use the policyID to connect to the corresponding policyCategories_ Onyx key. With that, we can confirm that the policy has categories enabled and populated (we'll know this because we load categories when opening the MoneyRequestConfirmPage beforehand).
Note: If this is not implemented yet, refer to the Wave 5 doc to implement the workspace policyID connection in the MoneyRequestConfirm component cc @neil-marcellini

function MoneyRequestConfirmationList(props) {

// ...

    return (
        <OptionsSelector>

            // ... Other Menu Items

            {props.policyCategories != null && (
                <MenuItemWithTopDescription
                    shouldShowRightIcon={!props.isReadOnly}
                    title={props.iouCategory}
                    description={translate('common.category')}
                    onPress={() => Navigation.navigate(ROUTES.getMoneyRequestCategoryRoute(props.iouType, props.reportID))}
                    style={[styles.moneyRequestMenuItem, styles.mb2]}
                    disabled={didConfirm || props.isReadOnly}
                />
            )}



        </OptionsSelector>
    );

withOnyx({

    // ... Other Onyx Connection props

    policyCategories: {
        key: ({policyID}) => `${ONYXKEYS.COLLECTION.POLICY_CATEGORIES}${policyID}`,
    },
}),

• We'll create a new method ROUTES.getMoneyRequestCategoryRoute that links to ${iouType}/new/category/${reportID}.
• This route will take you to the Category Picker.
• The category selector will always sit in the same section as Merchant / Date. This will ensure that it is hidden behind the "Show more" dropdown just like those fields.
• The category selector will follow the same offline patterns as the Merchant and Date fields.

Category Picker

We'll use a single page to render both the "simple" categories selector and the more complex category selector (for when you have >= 8 categories). Both versions of the page will mainly utilize an OptionsList component. This will support sections, custom container styling, keyboard controls, and search via text input already.

The CategoryPicker will take in the following props:

• onSubmit: Callback function to fire the moment a category is selected.
  • For the case of creating a Money Request, this saves the selected category (or lack thereof) to the local Money Request. This will be called from the onSelectRow function we pass to the OptionsSelector.
• policyID: Used so that we may fetch the corresponding policy categories from Onyx
• categoryList (Onyx prop): The category list from the COLLECTION_POLICY_CATEGORIES Onyx key.
• recentlyUsedCategories (Onyx prop): The recentlyUsedCategories NVP of the user stored in Onyx.

Less than 8 categories

When a policy has less than 8 categories, rendering the sections for the OptionsSelector is very simple. We'll have a single, untitled section with each of our category names passed as options. The shouldShowTextInput prop will be passed as false.

More than 8 categories

When a policy has 8 or more categories, we'll render up to three sections, as well as show the text input for search.

The sections will be as follows, and will be returned by a method similar to what we use for the MoneyRequestParticipantsSelector:

• Selected category: This section will have no title and only will display if a category is already on the expense. That category will render as selected as well as be omitted from the "All" and "Recents" sections below.
• Recents: This section will have a title. These will be the 5 most recent categories of the policy for the user - less the selected category if applicable. It will be grabbed from the recentlyUsedCategories prop. We'll only display this section if the array of recently used categories for the policies is non-empty.
• All: This will also have a title. This will be all the categories on the policy passed as options - less the selected category if applicable.

We'll utilize some methods in CategoryPicker to help us display our options:

• getOptionTree: In order to format the parent sections we'll need to utilize a helper method to transform the "parent category:child category" format into a format that is easier to interpret. We can follow a similar logic to what we have with buildOptions for the categorySelector in OldDot. This will still be used even if we're displaying < 8 categories.
  

• getOptions: When there is text in the search bar, we'll hide the Recents section and flatten the options (including the selected option) as one unified section. They will use their original names (i.e. in "parent: child" format). We'll filter the options using the getNewChatOptions method, passing in our search term. If our search term ever goes back to an empty string, we'll change back to using the result of getOptionTree above, as well as re-showing all sections.
  

Other details across both cases

• If a category name is super long, it will continue onto a second line in the same OptionRow.
• If there are no results matching the search term, we'll show "No results found", which is the default behavior already.

CreateTransaction

The action to create transactions, both for distance and regular requests already exists or will exist. The updates for each are quite simple. We'll need to update createTransaction to incorporate the selected category. We'll also need to update createDistanceRequest to incorporate the category as well.

---

Automated Tests

We'll add tests for the CategoryPicker logic, most notably around creating the list of options to be displayed. We'll test that the following criteria are satisfied:

getOptionTree

• Sub-categories are properly indented when returned from getOptionTree.
• Multiple levels of sub-categories are indented properly when returned from getOptionTree - and that alphabetical order is still honored from the original parent category.
• If a parent category is not in the category list, it is disabled when returned from getOptionTree.
• Sub-categories are shown in "parent: child" format when:
  • Shown as the selected category in the request detailed view
  • Shown as the top selected category when there are more than 8 categories
  • Appearing in search results
  • Appearing in the recent categories section
  • Appearing in the "All" section but it's parent category is the currently selected category.

getOptions

• All three sections (Selected category, Recents, All) are present when there are recentlyUsedCategories for the policy, a category has already been selected, and there are more than 8 categories.
• The selected category is not present in "All" when there are more than 8 categories.
• There are only two sections (Recents, All) present when there are recentlyUsedCategories for the policy and there are more than 8 categories, but no category is selected.
• There is only one section displayed (All) when no category is selected and recentlyUsedCategories for the policy are empty.
• When there are less than 8 categories:
  • Only one section is displayed with no title
  • "Recents" are not displayed even though recentlyUsedCategories is present and has values
  • The selected category shows within the list instead

---

Implementation:

• Category MenuItem and CategoryPicker component #25470
  • Add a “Category” menu item to the Money Request screen.
  • Creates a basic Category Picker screen. It includes: title, description and simple list.
• Category list helpers #25777
  • Create getOptionTree function, to format the parent sections we'll need to utilize a helper method to transform the "Parent: Child" category format into a format that is easier to interpret.
  • Extend getOptions function, to split categories by sections.
  • Extend getNewChatOptions function, to filter the options using the function.
  • Implement tests for as many cases as possible.
• Categories UI/UX #26501
  • Connect previously created categories simple
  • Enable categories for manual and distance requests.
  • Send a selected category among other request details

[melvin-bot]

Triggered auto assignment to @joekaufmanexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[melvin-bot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[melvin-bot]

Triggered auto assignment to @Christinadobrzyn (NewFeature), see https://stackoverflowteams.com/c/expensify/questions/14418#:~:text=BugZero%20process%20steps%20for%20feature%20requests for more details.

[melvin-bot]

Triggered auto assignment to Design team member for new feature review - @shawnborton (NewFeature)

[rezkiy37]

Hi, I'm Michael (Mykhailo) from Callstack and I would like to work in this issue.

[waterim]

Hello, Im Artem from Callstack and I would like to take this issue as well.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[rezkiy37]

Already working on a fix.

[rezkiy37]

The PR already reviewing internally, public review gonna be soon.

[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 1.3.69-2 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• Categories UI/UX #26501

If no regressions arise, payment will be issued on 2023-09-21. 🎊

After the hold period is over and BZ checklist items are completed, please complete any of the applicable payments for this issue, and check them off once done.

• External issue reporter
• Contributor that fixed the issue
• Contributor+ that helped on the issue and/or PR

For reference, here are some details about the assignees on this issue:

• @waterim does not require payment (Contractor)
• @rezkiy37 does not require payment (Contractor)

As a reminder, here are the bonuses/penalties that should be applied for any External issue:

• Merged PR within 3 business days of assignment - 50% bonus
• Merged PR more than 9 business days after assignment - 50% penalty

[yuwenmemon]

@puneetlath can we close this?

[puneetlath]

I need to pay out the C+ that were involved. I'll do that tomorrow and then we can close.

[puneetlath]

Ok so it looks like we had three PRs here:

• Category MenuItem and CategoryPicker component #25470 (C+ @jjcoffee)
• Category list helpers #25777 (C+ @situchan)
• Categories UI/UX #26501 (C+ @abdulrahuman5196)

Does that all seem right? If so the payment summary would be:

• C+ @jjcoffee - $1000
• C+ @situchan - $1000
• C+ @abdulrahuman5196 - $500

All to be paid out via Upwork.

[jjcoffee]

@puneetlath I think @situchan and I both had our PR reviews from before the compensation was updated (Aug 30), so I wonder if it should be $1000 instead?

[situchan]

From #27509 (comment), seems like it's still applied to PRs created before announcement

[puneetlath]

Looks like you're right. I'll update that. Thanks for letting me know.

[puneetlath]

Upwork offers sent:
https://www.upwork.com/nx/wm/offer/26812985
https://www.upwork.com/nx/wm/offer/26812987
https://www.upwork.com/nx/wm/offer/26812991

[jjcoffee]

@puneetlath Offer accepted, thanks!

[puneetlath]

@situchan and @jjcoffee have been paid.

Now just waiting for @abdulrahuman5196 to accept the contract and we should be good to go here.

[yuwenmemon]

@puneetlath are we good to close here?

[puneetlath]

All paid now. Thanks everyone!