[ON HOLD][$2000] Android - Workspace is still selectable even after 'Create room' button has been pressed

[kbecciv]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Action Performed:

1. Go to android
2. Click on FAB menu
3. Click on New Room
4. Enter room name > select a workspace
5. (Important step )> Click on create room and immediately again select the workspace dropdown and notice that it is still clickable

Expected Result:

Workspace should not be selected when the 'create room' button has been pressed

Actual Result:

Workspace is still selectable even after 'Create room' button has been pressed

Workaround:

Unknown

Platforms:

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

• Android / native
• Android / Chrome
• iOS / native
• iOS / Safari
• MacOS / Chrome / Safari
• MacOS / Desktop

Version Number: 1.3.29-11
Reproducible in staging?: y
Reproducible in production?: y
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
Notes/Photos/Videos: Any additional supporting documentation

workspace.2.mp4

Screen.Recording.20230626.115123.New.Expensify.2.mp4

Expensify/Expensify Issue URL:
Issue reported by: @priya-zha
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1687430588059259

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~011eacb8f4d46da0d6
• Upwork Job ID: 1673652478476353536
• Last Price Increase: 2023-07-19

[melvin-bot]

Triggered auto assignment to @johncschuster (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[melvin-bot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[melvin-bot]

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

[melvin-bot]

Current assignee @johncschuster is eligible for the External assigner, not assigning anyone new.

[melvin-bot]

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

[Thanos30]

Proposal

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

Picker (Selection fields) are still enabled after the Create Room button is clicked, which allows the user to change the values.

What is the root cause of that problem?

The root cause of this problem is on the WorkspaceNewRoomPage.js file:

submit(values) {
        const policyMembers = _.map(_.keys(this.props.allPolicyMembers[`${ONYXKEYS.COLLECTION.POLICY_MEMBERS}${values.policyID}`]), (accountID) => Number(accountID));
        Report.addPolicyReport(values.policyID, values.roomName, values.visibility, policyMembers);
    }

When the submit function is called, this doesn't block the Pickers in any way, so while the action is fired, they are still enabled. We also need to make the actions after the submit asynchronously, so that it doesn't block our state from updating.

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

We should add an extra state on the component like that:

constructor(props) {
        super(props);

        this.state = {
            visibilityDescription: this.props.translate('newRoomPage.restrictedDescription'),
            isFormSubmitting: false, // New property for form submission state

        };

On the submit action, we should add the following:

submit(values) {
        const policyMembers = _.map(_.keys(this.props.allPolicyMembers[`${ONYXKEYS.COLLECTION.POLICY_MEMBERS}${values.policyID}`]), (accountID) => Number(accountID));
        this.setState({isFormSubmitting: true});
        setTimeout(() => {
            const policyMembers = _.map(_.keys(this.props.allPolicyMembers[`${ONYXKEYS.COLLECTION.POLICY_MEMBERS}${values.policyID}`]), (accountID) => Number(accountID));
            Report.addPolicyReport(values.policyID, values.roomName, values.visibility, policyMembers);
        }, 0);
    }

// We use SetTimeout with 0 delay, otherwise our component won't be updated to disable the fields.

*EDIT: I initially used the isDisabled prop on the Picker, but I noticed that this renders it into a Text field and it shows the value instead of the label, which is something we don't want for the users. My new approach is to disable the Pickers via their View parents

OLD IMPLEMENTATION:

<Picker
                            inputID="policyID"
                            label={this.props.translate('workspace.common.workspace')}
                            placeholder={{value: '', label: this.props.translate('newRoomPage.selectAWorkspace')}}
                            items={workspaceOptions}
                            isDisabled={this.state.isFormSubmitting}
                        />

NEW IMPLEMENTATION:

<View style={styles.mb5} pointerEvents={this.state.isFormSubmitting ? 'none' : 'auto'}>
                        <Picker
                            inputID="policyID"
                            label={this.props.translate('workspace.common.workspace')}
                            placeholder={{value: '', label: this.props.translate('newRoomPage.selectAWorkspace')}}
                            items={workspaceOptions}
                        />
                    </View>

This one disables the Select fields without changing the looks.

This way, the selection fields / inputs will be disabled while the room is being created

[johncschuster]

Not overdue, Melvin. We're just getting proposals now.

@fedirjh, what do you think of the above proposal?

[fedirjh]

@Thanos30 I think the root cause is that we don't disable the Form input's edition after submission. Ideally, we should fix the Form and block any interaction after submission.

Regarding the solution, we should avoid using setTimeout as a workaround.

[Thanos30]

@fedirjh I could look into the Form inputs' disabling option if you prefer it this way.

The reason I am using the setTimeout, is because the Form submission is triggering an immediate navigation, and our issue is happening in between the navigation process. Within that small time space, the state update on the Form component isn't firing, since we are on the navigating process. That's why we use the setTimeout in order to do that on the background.

Feel free to test on your own environment if possible so you can check this first-hand.

Thanks for the feedback

[melvin-bot]

Looks like something related to react-navigation may have been mentioned in this issue discussion.

As a reminder, please make sure that all proposals are not workarounds and that any and all attempt to fix the issue holistically have been made before proceeding with a solution. Proposals to change our DeprecatedCustomActions.js files should not be accepted.

Feel free to drop a note in #expensify-open-source with any questions.

[fedirjh]

I could look into the Form inputs' disabling option if you prefer it this way.`

We should fix it globally, it may occur on other forms as well, so it would be ideal to address the root cause.

the state update on the Form component isn't firing

Maybe we should investigate that further, this is feels tricky to me. Not sure , but we can switch the order of execution, update state then submit the form.

[Thanos30]

We should fix it globally, it may occur on other forms as well, so it would be ideal to address the root cause.

I checked, I can follow the same logic inside the Form component so that it works like that everywhere.

Maybe we should investigate that further, this is feels tricky to me. Not sure , but we can switch the order of execution, update state then submit the form.

I tried that, as I mentioned above, the state update is asynchronous, so it still doesn't trigger. I understand that it sounds a bit tricky, in real life scenarios the Navigation will probably never take long enough for the user to be able to click on the selection fields again.

Debouncing the creation of the room and the navigation with a delay of 0 will simply run the actions on the background asynchronously, which allows us to remain on the same state and be able to update it. If you think about it, in most forms, there is an asynchronous function following up, so it's not that strange.

[melvin-bot]

@johncschuster, @fedirjh Whoops! This issue is 2 days overdue. Let's get this updated quick!

[melvin-bot]

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

[johncschuster]

@fedirjh what are your thoughts on @Thanos30's comment above?

[fedirjh]

@johncschuster I think we should wait for better proposal , actually we don't allow setTimeout solution and it seems like @Thanos30 has not updated his proposal to address that.

[Thanos30]

@fedirjh setTimeout will be used with the _.debounce() function which is broadly used throughout our codebase, but I do understand that it is used for different cases.

I couldn't figure out a way around this without debouncing the call so that it runs on the background (asynchronously) and not block the state update. If you want me to update my proposal to use the _debounce() method please let me know. If you dislike this approach of course it's okay, hopefully someone can come up with a different approach.

Thank you for the feedback

[johncschuster]

Not overdue, Melvin. We're still waiting on proposals

[johncschuster]

Thanks for the bump! That sounds good to me! Are we putting this on hold for #27025, or is there a different issue I can link to?

[johncschuster]

I've put the issue on hold. @fedirjh, can you confirm I have the right issue for the hold when you get a moment? Thank you!

[johncschuster]

Still holding.

[fedirjh]

can you confirm I have the right issue for the hold when you get a moment?

hey @johncschuster It should be on hold for #25397

[fedirjh]

Still on hold.

[fedirjh]

@johncschuster The create room flow has been changed. It now uses a push to page for workspace selection, which seems to improve the UX and fix the bug for me. @kbecciv could you please retest the issue?

CleanShot.2023-10-27.at.00.09.21.mp4

[fedirjh]

@johncschuster Can we retest if this bug still exists? please check my comment #21577 (comment)

[johncschuster]

Sure! @kbecciv, can you re-test that flow?

[kbecciv]

@johncschuster Checking, will update you shortly

[kbecciv]

Issue is not reproducible

Screen_Recording_20231109_120222_New.Expensify.mp4

[fedirjh]

Issue is not reproducible

@johncschuster Are we good to close this bug ?

[johncschuster]

Yes! Let's close it!