[$250] Non-editable rows on the workspace profile show a hover state #54090

m-natarajan · 2024-12-13T01:30:23Z

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

Version Number: 9.0.75-6
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?:
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @dannymcclain
Slack conversation (hyperlinked to channel name): expensify_bugs

Action Performed:

Prerequiste: Invite User B as employee to User A's Workspace

Login as user B
Open the workspace from settings
Hover over the profile and currency field

Expected Result:

No hover state as the fields are not editable

Actual Result:

Non-editable rows on the workspace profile show a hover state

Workaround:

Can the user still use Expensify without this being fixed? Have you informed them of the workaround?

Platforms:

Which of our officially supported platforms is this issue occurring on?

Screenshots/Videos

Add any screenshot/video evidence

CleanShot.2024-12-12.at.08.23.17.mp4

Recording.845.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~021867410578187381937
Upwork Job ID: 1867410578187381937
Last Price Increase: 2024-12-27
Automatic offers:

shubham1206agra | Contributor | 105546447

Issue Owner

Current Issue Owner: @akinwale

melvin-bot · 2024-12-13T01:30:34Z

Triggered auto assignment to @isabelastisser (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

Krishna2323 · 2024-12-13T01:48:32Z

Proposal

Please re-state the problem that we are trying to solve in this issue.

Non-editable rows on the workspace profile show a hover state

What is the root cause of that problem?

We are using the isDisabled property without shouldRemoveHoverBackground or shouldRemoveBackground prop.

App/src/pages/workspace/WorkspaceProfilePage.tsx

Lines 203 to 269 in 10bfe9a

    
               <MenuItemWithTopDescription 
        
                   title={policyName} 
        
                   titleStyle={styles.workspaceTitleStyle} 
        
                   description={translate('workspace.editor.nameInputLabel')} 
        
                   shouldShowRightIcon={!readOnly} 
        
                   disabled={readOnly} 
        
                   wrapperStyle={[styles.sectionMenuItemTopDescription, shouldUseNarrowLayout ? styles.mt3 : {}]} 
        
                   onPress={onPressName} 
        
                   shouldGreyOutWhenDisabled={false} 
        
                   shouldUseDefaultCursorWhenDisabled 
        
               /> 
        
           </OfflineWithFeedback> 
        
           {(!StringUtils.isEmptyString(policy?.description ?? '') || !readOnly) && ( 
        
               <OfflineWithFeedback 
        
                   pendingAction={policy?.pendingFields?.description} 
        
                   errors={ErrorUtils.getLatestErrorField(policy ?? {}, CONST.POLICY.COLLECTION_KEYS.DESCRIPTION)} 
        
                   onClose={() => Policy.clearPolicyErrorField(policy?.id ?? '-1', CONST.POLICY.COLLECTION_KEYS.DESCRIPTION)} 
        
               > 
        
                   <MenuItemWithTopDescription 
        
                       title={policyDescription} 
        
                       description={translate('workspace.editor.descriptionInputLabel')} 
        
                       shouldShowRightIcon={!readOnly} 
        
                       disabled={readOnly} 
        
                       wrapperStyle={styles.sectionMenuItemTopDescription} 
        
                       onPress={onPressDescription} 
        
                       shouldGreyOutWhenDisabled={false} 
        
                       shouldUseDefaultCursorWhenDisabled 
        
                       shouldRenderAsHTML 
        
                   /> 
        
               </OfflineWithFeedback> 
        
           )} 
        
           <OfflineWithFeedback 
        
               pendingAction={policy?.pendingFields?.outputCurrency} 
        
               errors={ErrorUtils.getLatestErrorField(policy ?? {}, CONST.POLICY.COLLECTION_KEYS.GENERAL_SETTINGS)} 
        
               onClose={() => Policy.clearPolicyErrorField(policy?.id ?? '-1', CONST.POLICY.COLLECTION_KEYS.GENERAL_SETTINGS)} 
        
               errorRowStyles={[styles.mt2]} 
        
           > 
        
               <View> 
        
                   <MenuItemWithTopDescription 
        
                       title={formattedCurrency} 
        
                       description={translate('workspace.editor.currencyInputLabel')} 
        
                       shouldShowRightIcon={!readOnly} 
        
                       disabled={hasVBA ? true : readOnly} 
        
                       wrapperStyle={styles.sectionMenuItemTopDescription} 
        
                       onPress={onPressCurrency} 
        
                       shouldGreyOutWhenDisabled={false} 
        
                       shouldUseDefaultCursorWhenDisabled 
        
                       hintText={hasVBA ? translate('workspace.editor.currencyInputDisabledText') : translate('workspace.editor.currencyInputHelpText')} 
        
                   /> 
        
               </View> 
        
           </OfflineWithFeedback> 
        
           {!!canUseSpotnanaTravel && shouldShowAddress && ( 
        
               <OfflineWithFeedback pendingAction={policy?.pendingFields?.address}> 
        
                   <View> 
        
                       <MenuItemWithTopDescription 
        
                           title={formattedAddress} 
        
                           description={translate('common.companyAddress')} 
        
                           shouldShowRightIcon={!readOnly} 
        
                           disabled={readOnly} 
        
                           wrapperStyle={styles.sectionMenuItemTopDescription} 
        
                           onPress={onPressAddress} 
        
                           shouldGreyOutWhenDisabled={false} 
        
                           shouldUseDefaultCursorWhenDisabled 
        
                       /> 
        
                   </View> 
        
               </OfflineWithFeedback> 
        
           )}

What changes do you think we should make in order to solve the problem?

We can pass shouldRemoveHoverBackground={readOnly} or shouldRemoveBackground={readOnly}.
We can keep isDisabled prop, and also add isInteractive prop. interactive={!readOnly}. While isInteractive alone would address the issue, the absence of isDisabled will result in a dimming effect when the field is pressed.
Note: we can only apply this to name and currency field because other fields are not shown to non-admins. We

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future? 

We can remove the style below because the hovered state is already handled here.

App/src/components/MenuItem.tsx

Line 622 in 10bfe9a

isHovered && interactive && !focused && !pressed && !shouldRemoveBackground && !shouldRemoveHoverBackground && styles.hoveredComponentBG,
We would also need to update the condition to:

!shouldRemoveBackground &&
    StyleUtils.getButtonBackgroundColorStyle(
        getButtonState(shouldRemoveHoverBackground && (focused || isHovered), pressed, success, disabled, interactive),
        true,
    ),
    
// OR

!shouldRemoveBackground && shouldRemoveHoverBackground &&
    StyleUtils.getButtonBackgroundColorStyle(
        getButtonState(focused || isHovered, pressed, success, disabled, interactive),
        true,
    ),

What alternative solutions did you explore? (Optional)

melvin-bot · 2024-12-13T03:25:53Z

Job added to Upwork: https://www.upwork.com/jobs/~021867410578187381937

melvin-bot · 2024-12-13T03:25:57Z

Triggered auto assignment to Contributor-plus team member for initial proposal review - @akinwale (External)

mkzie2 · 2024-12-13T05:44:07Z

Proposal

Please re-state the problem that we are trying to solve in this issue.

Non-editable rows on the workspace profile show a hover state

What is the root cause of that problem?

If the user is non-admin, disabled is true

App/src/pages/workspace/WorkspaceProfilePage.tsx

Line 208 in 29d546b

disabled={readOnly}

getButtonBackgroundColorStyle returns an empty style if the state is disabled

App/src/components/MenuItem.tsx

Line 619 in 29d546b

    
           StyleUtils.getButtonBackgroundColorStyle(getButtonState(focused || isHovered, pressed, success, disabled, interactive), true),

App/src/styles/utils/index.ts

Lines 1367 to 1375 in 29d546b

    
           getButtonBackgroundColorStyle: (buttonState: ButtonStateName = CONST.BUTTON_STATES.DEFAULT, isMenuItem = false): ViewStyle => { 
        
               switch (buttonState) { 
        
                   case CONST.BUTTON_STATES.PRESSED: 
        
                       return isMenuItem ? {backgroundColor: theme.buttonHoveredBG} : {backgroundColor: theme.buttonPressedBG}; 
        
                   case CONST.BUTTON_STATES.ACTIVE: 
        
                       return isMenuItem ? {backgroundColor: theme.border} : {backgroundColor: theme.buttonHoveredBG}; 
        
                   case CONST.BUTTON_STATES.DISABLED: 
        
                   case CONST.BUTTON_STATES.DEFAULT: 
        
                   default:

and we don't disable the hover style here if disabled prop is true

App/src/components/MenuItem.tsx

Line 622 in 29d546b

    
           isHovered && interactive && !focused && !pressed && !shouldRemoveBackground && !shouldRemoveHoverBackground && styles.hoveredComponentBG,

Then the hover style is still applied for a disabled menu item

What changes do you think we should make in order to solve the problem?

We should not apply the hover style for the disabled items here, we can add !disabled check here

isHovered && interactive && !focused && !pressed && !disabled && !shouldRemoveBackground && !shouldRemoveHoverBackground && styles.hoveredComponentBG,

App/src/components/MenuItem.tsx

Line 622 in 29d546b

    
           isHovered && interactive && !focused && !pressed && !shouldRemoveBackground && !shouldRemoveHoverBackground && styles.hoveredComponentBG,

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

NA

What alternative solutions did you explore? (Optional)

We can use interactive={! readOnly} then we can remove shouldGreyOutWhenDisabled and shouldUseDefaultCursorWhenDisabled since the interactive prop already handles the default cursor style. We should update both the name and currency items.

App/src/pages/workspace/WorkspaceProfilePage.tsx

Lines 208 to 213 in 29d546b

    
               disabled={readOnly} 
        
               wrapperStyle={[styles.sectionMenuItemTopDescription, shouldUseNarrowLayout ? styles.mt3 : {}]} 
        
               onPress={onPressName} 
        
               shouldGreyOutWhenDisabled={false} 
        
               shouldUseDefaultCursorWhenDisabled 
        
           />

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

ChavdaSachin · 2024-12-13T07:20:45Z

Proposal

Please re-state the problem that we are trying to solve in this issue.

Non-editable rows on the workspace profile show a hover state

What is the root cause of that problem?

MenuItems here are made disabled instead it should be in-interactive. And side Effects of disabled are over written.

App/src/pages/workspace/WorkspaceProfilePage.tsx

Lines 203 to 213 in 29d546b

    
           <MenuItemWithTopDescription 
        
               title={policyName} 
        
               titleStyle={styles.workspaceTitleStyle} 
        
               description={translate('workspace.editor.nameInputLabel')} 
        
               shouldShowRightIcon={!readOnly} 
        
               disabled={readOnly} 
        
               wrapperStyle={[styles.sectionMenuItemTopDescription, shouldUseNarrowLayout ? styles.mt3 : {}]} 
        
               onPress={onPressName} 
        
               shouldGreyOutWhenDisabled={false} 
        
               shouldUseDefaultCursorWhenDisabled 
        
           />

What changes do you think we should make in order to solve the problem?

Use appropriate props here, interactive prop is specially designed for such purpose.

Pass interactive={!readOnly} and remove props disabled and supporting props passed to overwrite side effects shouldGreyOutWhenDisabled and shouldUseDefaultCursorWhenDisabled at following places.

workspace Title
Workspace Description
Currency
Company Address

++    interactive={!readOnly}

--    disabled={readOnly}
--    shouldGreyOutWhenDisabled={false}
--    shouldUseDefaultCursorWhenDisabled

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

shubham1206agra · 2024-12-13T07:45:24Z

Proposal

Please re-state the problem that we are trying to solve in this issue.

Non-editable rows on the workspace profile show a hover state

What is the root cause of that problem?

In https://github.com/Expensify/App/blob/29d546b9fc25fab8c30d9aebe9fee501e696bada/src/pages/workspace/WorkspaceProfilePage.tsx

MenuItemWithTopDescription are made disabled instead of non-interactive, which does not disable the hover styling

App/src/pages/workspace/WorkspaceProfilePage.tsx

Lines 203 to 213 in 29d546b

    
           <MenuItemWithTopDescription 
        
               title={policyName} 
        
               titleStyle={styles.workspaceTitleStyle} 
        
               description={translate('workspace.editor.nameInputLabel')} 
        
               shouldShowRightIcon={!readOnly} 
        
               disabled={readOnly} 
        
               wrapperStyle={[styles.sectionMenuItemTopDescription, shouldUseNarrowLayout ? styles.mt3 : {}]} 
        
               onPress={onPressName} 
        
               shouldGreyOutWhenDisabled={false} 
        
               shouldUseDefaultCursorWhenDisabled 
        
           />

What changes do you think we should make in order to solve the problem?

We need to solve a bug with interactive first. When we press the menuitem when interactive={false}, we see a dimming effect. This happens due to opacity being applied on pressed here

App/src/components/MenuItem.tsx

Line 611 in 29d546b

activeOpacity={variables.pressDimValue}

Change this to

activeOpacity={!interactive ? 1 : variables.pressDimValue}

Now, use interactive prop instead of disabled here, and here

Diff below

++    interactive={!readOnly}
--    disabled={readOnly}
--    shouldGreyOutWhenDisabled={false}
--    shouldUseDefaultCursorWhenDisabled

Also, we can remove the disabled prop entirely from here and here, since we can't see these properties when non-admin member sees the page.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

NA since this is an UI change.

What alternative solutions did you explore? (Optional)

NA

bernhardoj · 2024-12-13T10:03:45Z

Proposal

Please re-state the problem that we are trying to solve in this issue.

The non-editable workspace field has a hovered style even though it's disabled.

What is the root cause of that problem?

When the item is disabled, we already return an empty style from getButtonBackgroundColorStyle, but since we manually added the hovered style (the last line below), the style is still added even when it's disabled.

App/src/components/MenuItem.tsx

Lines 618 to 622 in e27c5ea

    
           !shouldRemoveBackground && 
        
               StyleUtils.getButtonBackgroundColorStyle(getButtonState(focused || isHovered, pressed, success, disabled, interactive), true), 
        
           ...(Array.isArray(wrapperStyle) ? wrapperStyle : [wrapperStyle]), 
        
           shouldGreyOutWhenDisabled && disabled && styles.buttonOpacityDisabled, 
        
           isHovered && interactive && !focused && !pressed && !shouldRemoveBackground && !shouldRemoveHoverBackground && styles.hoveredComponentBG,

What changes do you think we should make in order to solve the problem?

I want to propose a different approach which is more complex but I think is cleaner. The goal is to remove this long line of conditions.

App/src/components/MenuItem.tsx

Line 622 in e27c5ea

    
           isHovered && interactive && !focused && !pressed && !shouldRemoveBackground && !shouldRemoveHoverBackground && styles.hoveredComponentBG,

To remove it properly, we need to go back first to find out why it was added. It started on this issue where the blockquote color is the same as the MenuItem hover color, so we want to use a different color. This PR then changes the color inside getButtonBackgroundColorStyle when the button state is ACTIVE. However, it causes a regression because ACTIVE can either mean HOVERED or FOCUSED for MenuItem (I checked all other usages and only MenuItem that does this).

So, a new PR is created to add the hover style manually.

isHovered && !pressed && styles.hoveredComponentBG,

But it causes another regression since the non-interactive MenuItem still received the hover style. So we patch it by adding interactive condition to fix it in this PR.

After several patches, we end up with this:

App/src/components/MenuItem.tsx

Line 622 in e27c5ea

    
           isHovered && interactive && !focused && !pressed && !shouldRemoveBackground && !shouldRemoveHoverBackground && styles.hoveredComponentBG,

Since we want to have a different BG color (only for MenuItem) for HOVERED and FOCUSED, we can separate the ACTIVE button state to HOVERED and FOCUSED. Here are the steps to fix this:

In getButtonState, replace isActive with isHovered and isFocused`, including the new state, FOCUSED and HOVERED.

function getButtonState(isHovered = false, isFocused = false, isPressed = false, ...) {
    if (isFocused) {
        return CONST.BUTTON_STATES.FOCUSED;
    }

    if (isHovered) {
        return CONST.BUTTON_STATES.HOVERED;
    }

In getButtonBackgroundColorStyle, replace the ACTIVE case with the FOCUSED and HOVERED case. FOCUSED and HOVERED will have the same BG color (which is the same as ACTIVE), except when it's HOVERED and it's a menu item.

getButtonBackgroundColorStyle: (...) => {
    switch (buttonState) {
        ...
        case CONST.BUTTON_STATES.FOCUSED:
            return isMenuItem ? {backgroundColor: theme.border} : {backgroundColor: theme.buttonHoveredBG};
        case CONST.BUTTON_STATES.HOVERED:
            return isMenuItem ? {backgroundColor: theme.hoverComponentBG} : {backgroundColor: theme.buttonHoveredBG};
        ...
    }
},

Remove this long conditional style.

App/src/components/MenuItem.tsx

Line 622 in e27c5ea

isHovered && interactive && !focused && !pressed && !shouldRemoveBackground && !shouldRemoveHoverBackground && styles.hoveredComponentBG,
Update the getButtonState usage of MenuItem.

App/src/components/MenuItem.tsx

Lines 618 to 619 in e27c5ea

    
           !shouldRemoveBackground && 
        
               StyleUtils.getButtonBackgroundColorStyle(getButtonState(focused || isHovered, pressed, success, disabled, interactive), true),

!shouldRemoveBackground &&
    StyleUtils.getButtonBackgroundColorStyle(getButtonState(isHovered && !shouldRemoveHoverBackground, focused, pressed, success, disabled, interactive), true),

App/src/components/MenuItem.tsx

Lines 697 to 698 in e27c5ea

    
           StyleUtils.getIconFillColor( 
        
               getButtonState(focused || isHovered, pressed, success, disabled, interactive),

and etc. isHovered will be the first param, isFocused will be the second param.

Update the rest of the usages of getButtonState.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

I think we can test getButtonBackgroundColorStyle and getButtonState to cover combinations of focused, disabled, etc.

akinwale · 2024-12-14T08:09:23Z

After reviewing the proposals here, we can move forward with @bernhardoj's proposal which provides a comprehensive approach to solving the issue, and would prevent further patching / workarounds down the line.

🎀👀🎀 C+ reviewed.

melvin-bot · 2024-12-14T08:09:37Z

Triggered auto assignment to @Julesssss, see https://stackoverflow.com/c/expensify/questions/7972 for more details.

shubham1206agra · 2024-12-14T09:40:04Z

Sorry @akinwale, but what problem does selected proposal solve? It does the logic refactoring but it does not solve the main issue. And what about this issue

When we press the menuitem when interactive={false}, we see a dimming effect.

melvin-bot · 2024-12-17T09:36:31Z

@akinwale, @Julesssss, @isabelastisser Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

Julesssss · 2024-12-17T10:17:13Z

Hey @akinwale, would you mind reviewing @shubham1206agra's comment about proposals? thanks

akinwale · 2024-12-18T06:47:49Z

Sorry @akinwale, but what problem does selected proposal solve? It does the logic refactoring but it does not solve the main issue. And what about this issue

When we press the menuitem when interactive={false}, we see a dimming effect.

Going with the refactor route would help prevent the wrong states from being applied to the menu item which would solve the main issue, and it effectively improves the maintainability of the code to prevent further patching or workarounds in the future.

cc @Julesssss

shubham1206agra · 2024-12-18T07:37:13Z

Sorry @akinwale, but what problem does selected proposal solve? It does the logic refactoring but it does not solve the main issue. And what about this issue

When we press the menuitem when interactive={false}, we see a dimming effect.

Going with the refactor route would help prevent the wrong states from being applied to the menu item which would solve the main issue, and it effectively improves the maintainability of the code to prevent further patching or workarounds in the future.

cc @Julesssss

Sorry @akinwale, but my question still stands. How does this refactoring solve the current issue? I understand the proposal tries to split states for hovered and focused. But it does not solve the root issue since this is an incomplete proposal, and we should not undertake such refactoring without advise from design team. Plus, no other proposal offers any workaround. It just suggests usage of correct params, which selected proposal does not.

Plus, you are opening yourself for tons of regression.

When we press the menuitem when interactive={false}, we see a dimming effect.

This is still not answered yet.

akinwale · 2024-12-18T10:28:24Z

Sorry @akinwale, but what problem does selected proposal solve? It does the logic refactoring but it does not solve the main issue. And what about this issue

When we press the menuitem when interactive={false}, we see a dimming effect.

Going with the refactor route would help prevent the wrong states from being applied to the menu item which would solve the main issue, and it effectively improves the maintainability of the code to prevent further patching or workarounds in the future.
cc @Julesssss

Sorry @akinwale, but my question still stands. How does this refactoring solve the current issue? I understand the proposal tries to split states for hovered and focused. But it does not solve the root issue since this is an incomplete proposal, and we should not undertake such refactoring without advise from design team. Plus, no other proposal offers any workaround. It just suggests usage of correct params, which selected proposal does not.

Plus, you are opening yourself for tons of regression.

The refactor introduces better handling of the combination of styles which would also prevent the hover styles from being applied when the menu item is disabled. It is also mostly geared towards code, not design. Being wary of regressions shouldn't be a hindrance to improving the codebase. I do agree however, that the proposal does not completely solve the issue.

When we press the menuitem when interactive={false}, we see a dimming effect.

This is still not answered yet.

I initially missed this. Since the bug is related to the interactive prop affecting the active opacity of the menu item, it looks like your solution addresses the underlying cause.

@Julesssss We can move forward with @shubham1206agra's proposal here.

bernhardoj · 2024-12-18T10:39:32Z

When we press the menuitem when interactive={false}, we see a dimming effect.

This is still not answered yet.

I initially missed this. Since the bug is related to the interactive prop affecting the active opacity of the menu item, it looks > like your solution addresses the underlying cause.

This isn't a problem in my proposal since we don't use interactive, and instead keep the disabled props.

shubham1206agra · 2024-12-18T10:55:20Z

When we press the menuitem when interactive={false}, we see a dimming effect.

This is still not answered yet.

I initially missed this. Since the bug is related to the interactive prop affecting the active opacity of the menu item, it looks > like your solution addresses the underlying cause.

This isn't a problem in my proposal since we don't use interactive, and instead keep the disabled props.

This is even more problematic since this introduces new design interface.

bernhardoj · 2024-12-18T10:58:17Z

new design interface

Can you point out which one? I don't think there is any new interface is added from my proposal

shubham1206agra · 2024-12-18T11:03:21Z

new design interface

Can you point out which one? I don't think there is any new interface is added from my proposal

You just changed the design of how disabled works. Disabled does not mean non-interactive.

bernhardoj · 2024-12-18T11:14:35Z

I don't think I changed the design, instead, I fixed it. Why should a disabled pressable show a hover style? If you use PressableWithFeedback and apply hoverDimmingValue < 1, the hover won't be applied if it's disabled.

Before #43987, disabled MenuItem won't show the hover, but after the PR, now the hover is applied. So, #43987 is the one that changes it, and my proposal will fix it.

shubham1206agra · 2024-12-18T11:54:08Z

I don't think I changed the design, instead, I fixed it. Why should a disabled pressable show a hover style? If you use PressableWithFeedback and apply hoverDimmingValue < 1, the hover won't be applied if it's disabled.

Before #43987, disabled MenuItem won't show the hover, but after the PR, now the hover is applied. So, #43987 is the one that changes it, and my proposal will fix it.

Sorry, but then what is the difference between non-interactive and disabled fields?

bernhardoj · 2024-12-18T12:19:48Z

There isn't a design guideline about that, but looking at the code, interactive is like the subset of disabled.

shubham1206agra · 2024-12-18T12:27:08Z

There isn't a design guideline about that, but looking at the code, interactive is like the subset of disabled.

In what way?

melvin-bot · 2024-12-20T16:00:05Z

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

isabelastisser · 2024-12-20T21:34:49Z

FYI, I will be OOO from Dec 23 to Jan 6, so please reassign the issue to another team member for urgency, IF needed.

melvin-bot · 2024-12-24T09:29:51Z

@akinwale, @Julesssss, @isabelastisser Eep! 4 days overdue now. Issues have feelings too...

melvin-bot · 2024-12-26T09:27:48Z

@akinwale, @Julesssss, @isabelastisser Still overdue 6 days?! Let's take care of this!

melvin-bot · 2024-12-27T09:01:25Z

@akinwale @Julesssss @isabelastisser this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

melvin-bot · 2024-12-27T16:00:07Z

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

melvin-bot · 2024-12-30T09:44:39Z

@akinwale, @Julesssss, @isabelastisser 10 days overdue. Is anyone even seeing these? Hello?

melvin-bot · 2025-01-01T09:16:14Z

@akinwale, @Julesssss, @isabelastisser 12 days overdue now... This issue's end is nigh!

Julesssss · 2025-01-03T11:40:52Z

I prefer @bernhardoj's button logic improvements in the long-term. But I agree it should be a wider choice we make in Slack. I would support you in making this proposal in Slack and we can tag the design team as an improvement.

For now though, lets stick with the fix from @shubham1206agra

melvin-bot · 2025-01-03T11:41:08Z

📣 @shubham1206agra 🎉 An offer has been automatically sent to your Upwork account for the Contributor role 🎉 Thanks for contributing to the Expensify app!

Offer link
Upwork job
Please accept the offer and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑‍💻
Keep in mind: Code of Conduct | Contributing 📖

Julesssss · 2025-01-06T16:44:47Z

PR is in progress

m-natarajan added Daily KSv2 Bug Something is broken. Auto assigns a BugZero manager. labels Dec 13, 2024

melvin-bot bot assigned isabelastisser Dec 13, 2024

isabelastisser added this to [#whatsnext] #quality Dec 13, 2024

isabelastisser added External Added to denote the issue can be worked on by a contributor Help Wanted Apply this label when an issue is open to proposals by contributors labels Dec 13, 2024

melvin-bot bot changed the title ~~Non-editable rows on the workspace profile show a hover state~~ [$250] Non-editable rows on the workspace profile show a hover state Dec 13, 2024

melvin-bot bot assigned akinwale Dec 13, 2024

melvin-bot bot assigned Julesssss Dec 14, 2024

melvin-bot bot added the Overdue label Dec 17, 2024

melvin-bot bot removed the Overdue label Dec 18, 2024

melvin-bot bot added the Overdue label Dec 20, 2024

muttmuure moved this to MEDIUM in [#whatsnext] #quality Dec 23, 2024

Julesssss mentioned this issue Jan 3, 2025

Use correct hover background for MenuItem New PR #43987

Merged

50 tasks

Julesssss assigned shubham1206agra Jan 3, 2025

melvin-bot bot removed the Help Wanted Apply this label when an issue is open to proposals by contributors label Jan 3, 2025

melvin-bot bot removed the Overdue label Jan 3, 2025

shubham1206agra mentioned this issue Jan 5, 2025

Fix workspace profile page on readOnly mode #54803

Merged

49 tasks

melvin-bot bot added Reviewing Has a PR in review Weekly KSv2 and removed Daily KSv2 labels Jan 5, 2025

[$250] Non-editable rows on the workspace profile show a hover state #54090

[$250] Non-editable rows on the workspace profile show a hover state #54090

Comments

m-natarajan commented Dec 13, 2024 • edited by melvin-bot bot Loading

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

melvin-bot bot commented Dec 13, 2024

Krishna2323 commented Dec 13, 2024 • edited Loading

Proposal

Please re-state the problem that we are trying to solve in this issue.

What is the root cause of that problem?

What changes do you think we should make in order to solve the problem?

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

What alternative solutions did you explore? (Optional)

melvin-bot bot commented Dec 13, 2024

melvin-bot bot commented Dec 13, 2024

mkzie2 commented Dec 13, 2024

Proposal

Please re-state the problem that we are trying to solve in this issue.

What is the root cause of that problem?

What changes do you think we should make in order to solve the problem?

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

What alternative solutions did you explore? (Optional)

ChavdaSachin commented Dec 13, 2024

Proposal

Please re-state the problem that we are trying to solve in this issue.

What is the root cause of that problem?

What changes do you think we should make in order to solve the problem?

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

What alternative solutions did you explore? (Optional)

shubham1206agra commented Dec 13, 2024

Proposal

Please re-state the problem that we are trying to solve in this issue.

What is the root cause of that problem?

What changes do you think we should make in order to solve the problem?

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

What alternative solutions did you explore? (Optional)

bernhardoj commented Dec 13, 2024

Proposal

Please re-state the problem that we are trying to solve in this issue.

What is the root cause of that problem?

What changes do you think we should make in order to solve the problem?

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

akinwale commented Dec 14, 2024

melvin-bot bot commented Dec 14, 2024

shubham1206agra commented Dec 14, 2024

melvin-bot bot commented Dec 17, 2024

Julesssss commented Dec 17, 2024

akinwale commented Dec 18, 2024

shubham1206agra commented Dec 18, 2024 • edited Loading

akinwale commented Dec 18, 2024 • edited Loading

bernhardoj commented Dec 18, 2024

shubham1206agra commented Dec 18, 2024

bernhardoj commented Dec 18, 2024

shubham1206agra commented Dec 18, 2024

bernhardoj commented Dec 18, 2024

shubham1206agra commented Dec 18, 2024

bernhardoj commented Dec 18, 2024

shubham1206agra commented Dec 18, 2024

melvin-bot bot commented Dec 20, 2024

isabelastisser commented Dec 20, 2024

FYI, I will be OOO from Dec 23 to Jan 6, so please reassign the issue to another team member for urgency, IF needed.

melvin-bot bot commented Dec 24, 2024

melvin-bot bot commented Dec 26, 2024

melvin-bot bot commented Dec 27, 2024

melvin-bot bot commented Dec 27, 2024

melvin-bot bot commented Dec 30, 2024

melvin-bot bot commented Jan 1, 2025

Julesssss commented Jan 3, 2025

melvin-bot bot commented Jan 3, 2025

Julesssss commented Jan 6, 2025

m-natarajan commented Dec 13, 2024 •

edited by melvin-bot bot

Loading

Krishna2323 commented Dec 13, 2024 •

edited

Loading

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future? 

shubham1206agra commented Dec 18, 2024 •

edited

Loading

akinwale commented Dec 18, 2024 •

edited

Loading