[No QA] Display workspaces in settings page #3630
Conversation
|
Looks good to me. I do wonder if we want to make the Workspace icon consistent across the board and have it use a green background everywhere? I think it uses a green background in the Create menu, so we might want to use it here as well as the workspace editor itself. |
|
I kinda like the idea of randomizing it to one of our colors like the default profile icons? |
|
|
||
| if (Permissions.canUseFreePlan(this.props.betas)) { | ||
| getPolicySummaries(); | ||
| getPolicyList(); |
There was a problem hiding this comment.
Curious if maybe we should fetch the policy list / policy summaries when the settings page opens so the policies will be up to date?
There was a problem hiding this comment.
Do you mean instead of or in addition to here? I did notice that if you delete a policy using the API, then the change won't appear unless E.cash refreshes. Not sure that's a problem though ... changes made to the policies in E.cash should update Onyx and trigger a refresh, right?
In other words, I'm not sure we should wait until the settings page opens to fetch the policies, but we could re-fetch them there if we want to keep E.cash and E.com more in sync?
There was a problem hiding this comment.
I was thinking only when opening the settings. But thinking more on that we'll maybe want to access the policies in the /workspace page as well (which may or may not be accessed via /settings).
I did notice that if you delete a policy using the API, then the change won't appear unless E.cash refreshes.
Right, I don't think we care about this or subscriptions for policies yet if you meant updating in E.cash when deleting the policy via OldDot.
changes made to the policies in E.cash should update Onyx and trigger a refresh, right?
Good question, but let's back up for a second. What changes are we talking about here?
I think for this project it would be mainly altering policy members + creating new policies. The logic for those other two places hasn't really been built out yet so I suppose we can leave this for now and decide what to do later. I mainly suggested that we should put this in the settings page since that seems like the earliest time when we'd need to access our list of policies and not really when the app inits (as we already front load a lot of API calls).
|
Random design feedback but curious if this hover style is correct as all the other hover styles are darkening the already grey areas e.g. What we have now for non workspace icon on hover... workspace icon in this PR what I'd expect to see based on the behavior of darkening the grey area further... anyways pretty small detail but curious if @shawnborton has a preference here. |
|
I agree with you Marc, but if we make this icon use a green background to match the other areas where we show the new workspace, I would say we don't even need a hover style for the icon itself. Especially when we plan to have user uploaded avatars there, I don't think we need a hover style for the avatar that is shown. |
# Conflicts: # src/components/MenuItem.js
|
Style and code updated 👍
|
| * @returns {Object} | ||
| */ | ||
| function getSimplifiedPolicyObject(fullPolicy) { | ||
| return { | ||
| ID: fullPolicy.id, |
There was a problem hiding this comment.
NAB, probably would make this lower case to match the API.
|
✋ 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 in version: 1.0.71-1🚀
|
|
🚀 Deployed to production in version: 1.0.73-3🚀
|
Details
Displays free policies (workspaces) in the settings page.
Fixed Issues
Fixes https://github.com/Expensify/Expensify/issues/166038
Tests
freeQA Steps
No QA for now.
Tested On
Screenshots
Web
Mobile Web
Desktop
iOS
Android