-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix/35134: Auto select category and tag #35862
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:
|
useEffect(() => { | ||
const enabledCategories = _.filter(policyCategories, (category) => category.enabled); | ||
if (iouCategory || !shouldShowCategories || enabledCategories.length !== 1) { | ||
if (iouCategory || !shouldShowCategories || enabledCategories.length !== 1 || !isCategoryRequired) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
asked in slack
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@puneetlath What do you think about this comment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jjcoffee Yes. It makes sense that will keep using canUseViolations
. I updated PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
@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? 🙏 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 Issues
section aboveTests
sectionOffline steps
sectionQA steps
sectiontoggleReport
and notonIconClick
)myBool && <MyComponent />
.src/languages/*
files and using the translation methodWaiting for Copy
label for a copy review on the original GH to get the correct copy.STYLE.md
) were followedAvatar
, I verified the components usingAvatar
are working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
)Avatar
is modified, I verified thatAvatar
is working as expected in all cases)Design
label so the design team can review the changes.ScrollView
component to make it scrollable when more elements are added to the page.main
branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTest
steps.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