[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 |
rojiphil
left a comment
There was a problem hiding this comment.
@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
approverto 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.
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
|
|
||
| // 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.
@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.
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.
@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.
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.
This doesn't feel like a blocker.
There was a problem hiding this comment.
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.
| "jest": "bin/jest.js" | ||
| } | ||
| }, | ||
| "node_modules/jest-expo/node_modules/@babel/code-frame": { |
There was a problem hiding this comment.
@BrtqKr Did this change got introduced unintended as these seem unrelated to our current scope here?
There was a problem hiding this comment.
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.
This also doesn't seem like a blocker.
|
Otherwise the code looks good and the feature works well. |
rojiphil
left a comment
There was a problem hiding this comment.
@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
approverdoes not change.
- Also, let us add the following so that QA can test
categoriestoo
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.
| 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.
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 🚀
|
| <Text style={[styles.textNormal, styles.textStrong, styles.mv3]}>{translate('workspace.tags.tagRules')}</Text> | ||
| </View> | ||
| <MenuItemWithTopDescription | ||
| title={tagApprover ?? ''} |
There was a problem hiding this comment.
This change caused a regression #52678. We should show the user name instead of email if the user name is not empty
| const styles = useThemeStyles(); | ||
| const {translate} = useLocalize(); | ||
|
|
||
| const tagApprover = PolicyUtils.getTagApproverRule(policyID, tagName)?.approver; |
There was a problem hiding this comment.
This page didn’t re-render when the policy updates. For issue #57514, we want to see the checkmark immediately after selecting an approver, even though the page closes soon after. Fixed by using the usePolicy() hook.
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 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-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