fix: categorize all expense switch is not disabled#39036
fix: categorize all expense switch is not disabled#39036luacmartins merged 13 commits intoExpensify:mainfrom
Conversation
Screen.Recording.2024-03-27.at.19.10.58.mov |
|
@tienifr yes, I think navigating to the more features page makes sense in this case. cc @JmillsExpensify |
Reviewer Checklist
Screenshots/VideosAndroid: NativeScreen.Recording.2024-04-03.at.6.31.00.in.the.evening.movAndroid: mWeb ChromeScreen.Recording.2024-04-02.at.10.09.04.at.night.moviOS: NativeScreen.Recording.2024-04-02.at.10.32.24.at.night.moviOS: mWeb SafariScreen.Recording.2024-04-02.at.10.28.15.at.night.movMacOS: Chrome / SafariScreen.Recording.2024-04-02.at.9.20.24.at.night.movMacOS: DesktopScreen.Recording.2024-04-03.at.6.37.24.in.the.evening.mov |
I think we should fix this behavior, it doesn't seem to be something we can ignore. if it is not possible lets use other alternatives. Screen.Recording.2024-03-27.at.11.13.37.at.night.mov |
|
Yea, let's navigate the user to the more features page |
@luacmartins Is this ideal? i don't see the need to navigate away to that page. it'll definitely be logged as a bug. |
|
@getusha @luacmartins I resolved all the comments |
|
cc @JmillsExpensify what do you think? What should happen when the user disables the last enabled category? Currently we also turn off the categories features (since that's what we do in OldDot), but then they see the not found page. |
luacmartins
left a comment
There was a problem hiding this comment.
One minor comment and we're also pending confirmation on the desired behavior
src/libs/actions/Policy.ts
Outdated
| return acc; | ||
| }, {}), | ||
| }; | ||
| const shouldTurnOffCategoriesEnabled = !OptionsListUtils.hasEnabledOptions({...policyCategories, ...optimisticPolicyCategoriesData}); |
There was a problem hiding this comment.
| const shouldTurnOffCategoriesEnabled = !OptionsListUtils.hasEnabledOptions({...policyCategories, ...optimisticPolicyCategoriesData}); | |
| const shouldDisableRequiresCategory = !OptionsListUtils.hasEnabledOptions({...policyCategories, ...optimisticPolicyCategoriesData}); |
|
@luacmartins I resolved all your comments |
|
Also, I updated screenshots and test steps |
luacmartins
left a comment
There was a problem hiding this comment.
@getusha all yours. Let's get this one merged!
|
Nice! Thanks for updating that! @getusha are you available to continue your review? Let's get this one merged! |
Yes 🙂 |
@tienifr QA steps is not clear, can you update it to something like this? |
|
@getusha I updated test steps |
|
Screen.Recording.2024-04-02.at.8.57.11.in.the.evening.mov@luacmartins It looks like a backend issue |
|
I can work on a fix for that in the backend. Let's not block this PR on that |
| }, | ||
| ], | ||
| }; | ||
| if (shouldDisableRequiresCategory) { |
There was a problem hiding this comment.
can we do the same for deleteWorkspaceCategories?
App/src/libs/actions/Policy.ts
Line 3439 in 5986481
Screen.Recording.2024-04-02.at.9.55.11.at.night.mov
There was a problem hiding this comment.
I updated to do the same when deleting category
src/libs/OptionsListUtils.ts
Outdated
| */ | ||
| function hasEnabledOptions(options: PolicyCategories | PolicyTag[]): boolean { | ||
| return Object.values(options).some((option) => option.enabled); | ||
| function hasEnabledOptions(options: PolicyCategories | PolicyTag[], shouldContainPendingDeleteOption = true): boolean { |
There was a problem hiding this comment.
Why do we need shouldContainPendingDeleteOption? Don't we always want to include those?
There was a problem hiding this comment.
If we do not use shouldContainPendingDeleteOption: Assume that all our categories are enabled. If we go offline and then delete all our categories, the hasEnabledOptions still returns true, which leads to the user still can toggle the "Required categories" switch
There was a problem hiding this comment.
Correct, but that's what I meant. Don't we always want to filter our pending delete categories when checking for hasEnabledOptions?
There was a problem hiding this comment.
Correct, but that's what I meant. Don't we always want to filter our pending delete categories when checking for hasEnabledOptions?
+1
There was a problem hiding this comment.
I updated based on this suggestion
|
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
|
🚀 Deployed to production by https://github.com/Julesssss in version: 1.4.60-13 🚀
|

Details
Fixed Issues
$ #37508
PROPOSAL: #37508 (comment)
Tests
Precondition:
Offline tests
QA Steps
Precondition:
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectiontoggleReportand notonIconClick)myBool && <MyComponent />.src/languages/*files and using the translation methodSTYLE.md) were followedAvatar, I verified the components usingAvatarare working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))Avataris modified, I verified thatAvataris working as expected in all cases)Designlabel and/or tagged@Expensify/designso the design team can review the changes.ScrollViewcomponent to make it scrollable when more elements are added to the page.mainbranch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTeststeps.Screenshots/Videos
Android: Native
Screen.Recording.2024-03-29.at.11.29.40.mov
Android: mWeb Chrome
Screen.Recording.2024-03-29.at.11.43.00.mov
iOS: Native
Screen.Recording.2024-03-29.at.11.49.53.mov
iOS: mWeb Safari
Screen.Recording.2024-03-29.at.11.45.30.mov
MacOS: Chrome / Safari
Screen.Recording.2024-03-29.at.11.23.43.mov
MacOS: Desktop
Screen.Recording.2024-03-29.at.11.25.27.mov