-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
[OldDot Rules Migration] Tag rules #48325
[OldDot Rules Migration] Tag rules #48325
Conversation
Hey! I see that you made changes to our Form component. Make sure to update the docs in FORMS.md accordingly. Cheers! |
The PRs we were waiting on are now deployed or merged so we can take this off HOLD. |
@marcaaron, it seems to be in a different field than I initially expected, but I've applied the changes and it's working. I believe we can pass it on for review. |
@BrtqKr I will review the PR today. Meanwhile, can you please resolve the conflicts? Thanks |
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.
@BrtqKr I have a few observations as mentioned below but the overall code looks super good though:
- Once an approver is selected, we do not allow deselecting the
approver
to set it tonone
. I think we need to support this considering that OldDot supports this. - The test steps in PR mentions this:
Verify that disabling tags in more features, disables approver as well
Neither do I see any implementation for this nor do I see any reference to this in test videos. Have we missed implementing this? Also, what would disables approver
mean here? I think it will help QA if we can further break down the test steps
|
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.
2. That's an error in the description, I meant rules and that's already implemented
@BrtqKr Thanks for the changes. The removal feature works fine but the feature of disabling approvers does not seem to be implemented yet as we do for category approver rules. Here is a test video demonstrating this. Please have a look. Thanks
48325-disabledapprover.mp4
if I understand correctly the condition should probably be uniform and it's been missing for the categories. It's already applied with the remaining fixes |
I've removed the offline pattern and added category/tag renaming in the rules. I believe this would be everything Screen.Recording.2024-09-18.at.01.57.14.mov |
src/libs/actions/Policy/Policy.ts
Outdated
@@ -2578,7 +2578,10 @@ function createWorkspaceFromIOUPayment(iouReport: OnyxEntry<Report>): WorkspaceF | |||
}); | |||
|
|||
// We need to move the report preview action from the DM to the workspace chat. | |||
const reportPreview = ReportActionsUtils.getParentReportAction(iouReport); | |||
const parentReport = ReportAcionsConnection.getAllReportActions()?.[`${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${iouReport.parentReportID}`]; |
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.
@BrtqKr Not sure if I am missing something here but why did we have to create ReportAcionsConnection
when we already have a utility ReportActionsUtils.getAllReportActions
?
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.
because we have a new eslint rule, which is forcing us to fix those things when we edit files containing deprecated code
well, not exactly eslint rule, but more like a check included inside of the one for eslint
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.
@BrtqKr Ah! I see. So, the deprecated function is getParentReportAction
but is there a need to create ReportAcionsConnection.getAllReportActions()
when ReportActionsUtils.getAllReportActions
gives us the same result?
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.
This is something I'll need to discuss separately, but from what I understand the main issue is that the rule has been prepared with components in mind, so it's expecting some kind of action to be taken anyway. I was thinking about the possible benefits of having a connection in one place instead of having logic split between different files, but as I said earlier, I'll discuss it in more detail with someone who has more context.
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.
This doesn't feel like a blocker.
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.
This is something I'll need to discuss separately
getParentReportAction
has been used in many places and I agree that this needs a separate discussion. Since this is not at all related to this issue, I would prefer not to include the changes for this in this PR. As and when there is a conclusion on the way forward, we can add the code changes. Anyway, I would leave the final decision on this to @marcaaron.
If we are leaving the code as it is, let us correct the spelling ReportAcionsConnection
.
@@ -27979,22 +27979,6 @@ | |||
"jest": "bin/jest.js" | |||
} | |||
}, | |||
"node_modules/jest-expo/node_modules/@babel/code-frame": { |
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.
@BrtqKr Did this change got introduced unintended as these seem unrelated to our current scope 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.
I haven't modified anything in package.json and I'm using the appropriate node version. The change was introduced right after merging main to this branch and reinstalling the packages, so I'd assume it wasn't indended, but it's 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.
This also doesn't seem like a blocker.
Otherwise the code looks good and the feature works well. |
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.
@BrtqKr I have left few suggestions related to test cases
- Let us add the below mentioned steps from 5th step onward in the existing test steps.
- Select an approver again
- Change the name of the tag
- Verify that the
approver
does not change.
- Also, let us add the following so that QA can test
categories
too
Repeat the above mentioned steps for categories and verify.
- Let us remove the following text from steps as QA will get confused:
Verify that disabling rules in more features, disables approver as well
@marcaaron Other than this comment, the code changes related to tag/category approver feature LGTM and works well too and I have completed the checklist.
Over to you for review.
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
@@ -3233,6 +3233,8 @@ export default { | |||
importedFromAccountingSoftware: 'Etiquetas importadas desde', | |||
glCode: 'Código de Libro Mayor', | |||
updateGLCodeFailureMessage: 'Se produjo un error al actualizar el código de Libro Mayor. Por favor, inténtelo nuevamente.', | |||
tagRules: 'Reglas de etiquetas', | |||
approverDescription: 'Aprobador', |
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.
NAB we could probably move this to the general
since it is used twice.
✋ 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/marcaaron in version: 9.0.39-0 🚀
|
🚀 Deployed to production by https://github.com/AndrewGable in version: 9.0.39-5 🚀
|
Holding on:
Details
Fixed Issues
$ #47016
$ #48977
PROPOSAL:
Tests
Verify that disabling rules in more features, disables approver as well
Offline tests
QA Steps
PR Author Checklist
### Fixed Issues
section aboveTests
sectionOffline steps
sectionQA steps
sectiontoggleReport
and notonIconClick
)myBool && <MyComponent />
.src/languages/*
files and using the translation methodSTYLE.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 and/or tagged@Expensify/design
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
Screen.Recording.2024-09-05.at.12.26.16.mov
Android: mWeb Chrome
Screen.Recording.2024-09-05.at.12.31.59.mov
iOS: Native
Simulator.Screen.Recording.-.iPhone.15.Pro.-.2024-09-05.at.11.58.45.mp4
iOS: mWeb Safari
Simulator.Screen.Recording.-.iPhone.15.Pro.-.2024-09-05.at.12.05.07.mp4
MacOS: Chrome / Safari
Screen.Recording.2024-09-05.at.10.41.15.mov
MacOS: Desktop
Screen.Recording.2024-09-05.at.12.36.56.mov