Fix/35134: Auto select category and tag#35862
Conversation
Reviewer Checklist
Screenshots/VideosAndroid: Nativeandroid-native-2024-02-06_11.43.02.mp4Android: mWeb Chromeandroid-chrome-2024-02-06_11.47.02.mp4iOS: Nativeios-native-2024-02-06_11.38.17.mp4iOS: mWeb Safariios-safari-2024-02-06_11.36.42.mp4MacOS: Chrome / Safaridesktop-chrome-2024-02-19_15.41.08.mp4MacOS: Desktopdesktop-app-2024-02-06_11.27.29.mp4 |
|
@dukenv0307 I think it's a bit clearer if the first test step is "Set up a workspace with only one tag and one category enabled". |
|
@dukenv0307 Could you add an Android native screenshot? |
|
@jjcoffee I fixed all your 3 comments |
|
@dukenv0307 Let's limit this to only auto-select if the category or tag is required (per this comment). I've not had feedback on whether or not we should hold for the multi-level tags PR (#34983) but it might be worth waiting for that anyway before doing any more work here. |
|
That PR should be getting merged today. |
|
Merged! @dukenv0307 Are you able to rework this to handle multi-level tags and to only auto-select if the tag/category is required? |
|
@jjcoffee Added the logic to handle:
|
There was a problem hiding this comment.
Using isCategoryRequired here means we'll get inconsistent behaviour vs tags as isCategoryRequired relies on canUseViolations being true, whereas the checks for the tags are not reliant on that. Do you think it's better to just use lodashGet(policy, 'requiresCategory', false) directly here?
There was a problem hiding this comment.
@jjcoffee With tags, we not only have isTagRequired which is canUseViolations && lodashGet(policy, 'requiresTag', false) but also have the required field for each tag in multiple level tags. So which required field should we use in this case? I am using the first one
There was a problem hiding this comment.
@dukenv0307 Ah good point! For multi-level tags I think we need to use the required field on each tag. For single-level tags however, we need to use isTagRequired as on oldDot this option is only available when multi-level tags are turned off (People must tag expenses):
Regarding my previous comment, I think it probably makes sense to just add canUseViolations to the tags to keep things consistent. Tags and Categories don't display the Required text unless canUseViolations is true so it makes sense for us to tie in with that I think!
| policyTagLists.forEach((tagList, index) => { | ||
| const enabledTags = _.filter(tagList.tags, (tag) => tag.enabled); | ||
| if (enabledTags.length !== 1 || !tagList.required || TransactionUtils.getTag(transaction, index)) { | ||
| if (enabledTags.length !== 1 || isMultipleLevelsTags ? !tagList.required : !isTagRequired || TransactionUtils.getTag(transaction, index)) { |
There was a problem hiding this comment.
| if (enabledTags.length !== 1 || isMultipleLevelsTags ? !tagList.required : !isTagRequired || TransactionUtils.getTag(transaction, index)) { | |
| if (enabledTags.length !== 1 || !tagList.required || TransactionUtils.getTag(transaction, index)) { |
Looking at this again, I think isTagRequired probably should/will be depreciated anyway as now all tags (including single level) will have the required property.
There was a problem hiding this comment.
I just checked again, and I see that the required field in each tag is not returned by BE in case multiple levels tags anymore. Can you help confirm?
There was a problem hiding this comment.
Hmm sounds like a bug to me. Can you ask on Slack to see if there's some reason for it?
There was a problem hiding this comment.
@jjcoffee I just test again and the tags data is always empty in case of multiple level tags. Do you encounter this, too?
There was a problem hiding this comment.
Haha oh sorry I responded on the issue first before seeing this. I'd vote for proceeding with the expectation that single-level tags will also have the required field set as the isTagRequired field seems obsolete to me. cc @puneetlath in case you have thoughts. (And sorry for all the pings!)
There was a problem hiding this comment.
@jjcoffee Oh. I agree with you. Currently, In case of multiple level tags but just have one tag list, we are considering them as single tags, that is not correct
There was a problem hiding this comment.
@puneetlath What do you think about this comment?
There was a problem hiding this comment.
|
Reported an unrelated bug here where all multi-level tags show as required if the workspace originally had "People must tag expenses" enabled. |
| let updatedTagsString = TransactionUtils.getTag(transaction); | ||
| policyTagLists.forEach((tagList, index) => { | ||
| const enabledTags = _.filter(tagList.tags, (tag) => tag.enabled); | ||
| if (isUndefined(tagList.required) || enabledTags.length !== 1 || !tagList.required || TransactionUtils.getTag(transaction, index)) { |
There was a problem hiding this comment.
How about introducing isTagListRequired here, both to keep things tidy but also so that we can use the canUseViolations flag for tags too?
There was a problem hiding this comment.
@jjcoffee Yes. It makes sense that will keep using canUseViolations. I updated PR
|
@dukenv0307 Can you merge main to fix conflicts? |
|
@puneetlath To summarise some of the implementation details here:
|
|
@dukenv0307 Sorry forgot to say, can you add to the test steps the pre-requisite that the violations beta needs to be enabled? 🙏 |
puneetlath
left a comment
There was a problem hiding this comment.
Just one comment.
@jjcoffee can you also make sure to report the BE issue in #expensify-bugs so we make sure it gets handled. You can cc me and yuwen.
@puneetlath Yuwen has pushed a fix, just waiting for it to hit production. |
|
✋ 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 staging by https://github.com/puneetlath in version: 1.4.49-0 🚀
|
|
🚀 Deployed to production by https://github.com/luacmartins in version: 1.4.50-5 🚀
|

Details
Fixed Issues
$ #35134
PROPOSAL: #35134 (comment)
Tests
Pre-requisite: Violations beta needs to be enabled
Offline tests
QA Steps
Pre-requisite: Violations beta needs to be enabled
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectiontoggleReportand notonIconClick)myBool && <MyComponent />.src/languages/*files and using the translation methodWaiting for Copylabel for a copy review on the original GH to get the correct copy.STYLE.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 so 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
Screencast.from.07-02-2024.17.55.51.webm
Android: mWeb Chrome
Screencast.from.06-02-2024.07.50.40.webm
iOS: Native
Screencast.from.06-02-2024.08.20.21.webm
iOS: mWeb Safari
Screencast.from.06-02-2024.07.53.12.webm
MacOS: Chrome / Safari
Screencast.from.06-02-2024.07.47.31.webm
MacOS: Desktop
Screencast.from.06-02-2024.08.09.19.webm