Repository navigation
Conversation
PR #100781 renders a Concierge message when a distance expense moves to another workspace and its rate is re-selected there. The Distance-Expenses FAQ still told members the rate is kept and a violation must be cleared by hand, which no longer happens. Correct it, name the exception in the Set-distance-rates FAQ, and fix a cross-link to an article that does not exist. Co-authored-by: dmkt9 <dmkt9@users.noreply.github.com>
MelvinBot
added
the
HelpDot
stephanieelliott
changed the title
|
@MelvinBot update your checklist: check all the checkboxes, then mark this PR as ready for review |
|
Done. I checked all 40 checkboxes in the PR description and marked this PR as ready for review. The PR description still says to hold the merge until Auth emits the |
Concierge reviewer checklist:
For more detailed instructions on completing this checklist, see How do I review a HelpDot PR as a Concierge Team member? |
|
@dmkt9 @bfitzexpensify One of you needs to copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button] |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 902248d9e9
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| Expensify automatically selects a rate from the destination Workspace, because the original Workspace's rates do not exist there. The rate is chosen the same way it is for a new Distance expense: the rate whose **Start date** and **End date** include the expense date. The distance and unit stay the same, and the amount is recalculated using the new rate. | ||
|
|
||
| If the rate isn’t valid in the new Workspace, the expense will show a “Rate not valid for this workspace” violation. Selecting a valid rate will update the expense. | ||
| Concierge posts a system message in the report reading `distance rates updated for the new workspace - [workspace name]`. The message names the destination Workspace but not a rate, because a report can hold several Distance expenses that each land on a different rate. To see what a single expense changed to, open that expense and check the "changed the rate" message in its thread. |
There was a problem hiding this comment.
At this revision, the App only formats and renders an incoming CONCIERGE_AUTO_SELECT_DISTANCE_RATE action; no code in the reviewed tree produces it, and the commit itself notes that Auth has not yet begun emitting the action or the per-expense update. Publishing this replacement now tells users that moving a report will recalculate rates and avoid the existing violation, even though current workspace moves still follow the old behavior. Keep the prior FAQ until the Auth-side change is deployed, then publish these instructions with it.
Useful? React with 👍 / 👎.
|
HelpDot Documentation Review Overall Assessment Scores Summary
Key Findings
Recommendations
Files Reviewed
Note: Detailed line-by-line feedback has been provided as inline comments. |
|
Consolidating to #101958 to avoid conflicts |
…nsify/workspaces
3 participants
Explanation of Change
Documents the automatic distance rate change that Render the Concierge system message for an automatic distance rate change surfaces, and corrects the one help-site FAQ that currently describes the old behavior.
The FAQ that is now wrong.
Distance-Expenses.mdanswered "What happens if a Distance expense is moved to a different Workspace?" with "it keeps its original unit and rate", then told members to resolve a "Rate not valid for this workspace" violation by hand. Neither half survives the new behavior: the rate is re-selected from the destination workspace automatically, so there is no stale rate left to violate. This is the substantive change in this PR — a member following the old FAQ would be waiting for a violation that never appears.The rewritten answer covers what a member actually sees:
distance rates updated for the new workspace - [workspace name]in the report. Copy taken fromsrc/languages/en.ts:1922.Two smaller fixes in the same area.
Set-distance-rates.mdsaid existing distance expenses "keep the rate that was applied when the expense was created" with no exceptions. That is true for editing a rate but not for a workspace move, so the answer now names the exception and links to the full explanation. Left in place rather than reworded wholesale, because the original claim is still correct for the case it was written about.Distance-Expenses.md:123linked to/articles/new-expensify/reports-and-expenses/Managing-Distance-Rates, which does not exist — the article is at/articles/new-expensify/workspaces/Set-distance-rates. Fixed while editing the same section. Unrelated to this PR's feature; drop it if you would rather keep this PR to one concern.Important
This should be held until the Auth side ships. PR #100781 renders the message but does not create it — its own QA Steps say "None. The Tests steps need a dev build for the devtools mock, so they can't run on staging until Auth emits the action." Auth still has to post the
CONCIERGEAUTOSELECTDISTANCERATEaction and the per-expenseMODIFIEDEXPENSEaction. Until then, this article describes behavior members cannot see, and the FAQ it replaces still describes what they get today. Please confirm the Auth timing before merging.UI labels. Distance rates, Add rate, Settings, Rate, Distance, Start date, and End date were checked against dev NewDot web. Change workspace was confirmed from
src/languages/en.tsrather than live, because that action only appears when an account has two or more eligible workspaces and the test account had one.Written against
docs/HELPSITE_NAMING_CONVENTIONS.md,docs/HELP_AUTHORING_GUIDELINES.md, anddocs/TEMPLATE.md. Both files already existed and already complied, so this keeps their structure and their existingWorkspacecapitalization rather than restyling untouched prose.Fixed Issues
$ #100556
PROPOSAL:
Tests
Docs-only change. No app code is touched, so there is nothing to exercise in the app.
npm run spell-changedpasses for both changed files. It was run on this branch and reportedFiles checked: 2, Issues found: 0.docs/articles/new-expensify/reports-and-expenses/Distance-Expenses.mdand confirm it matches what the app does once Auth emits the action — in particular that the rate is auto-selected rather than left invalid, and that the Concierge message names the workspace but no rate.src/languages/en.ts:1922exactly.https://help.expensify.com/articles/new-expensify/workspaces/Set-distance-rates.// TODO: The human co-author must confirm the documented behavior is correct before marking this PR as "ready for review". The behavior is not yet observable in the product — see the note in the Explanation of Change.
Offline tests
None. Help-site articles are static and have no offline behavior.
QA Steps
https://help.expensify.com/articles/new-expensify/reports-and-expenses/Distance-Expenses.https://help.expensify.com/articles/new-expensify/workspaces/Set-distance-ratesand verify the FAQ answer for Can I change the reimbursement rate for existing distance expenses? renders with its new second paragraph and working link.PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectionAvatar, I verified the components usingAvatarare working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))npm run compress-svg)Avataris modified, I verified thatAvataris working as expected in all cases)Designlabel and/or tagged@Expensify/designso the design team can review the changes.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
Android: mWeb Chrome
iOS: Native
iOS: mWeb Safari
MacOS: Chrome / Safari
@dmkt9, please review the files changed and confirm they reflect the current behavior. Then post a new comment saying
@MelvinBot mark this PR as ready for review.