Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create Group Chats + Splits. #37458

Merged
merged 45 commits into from
Mar 28, 2024
Merged

Conversation

waterim
Copy link
Contributor

@waterim waterim commented Feb 28, 2024

Details

Create Group Chats + Splits. Deprecate Group DM creation. Support viewing both Group DMs and Group Chats.

Fixed Issues

$ #32317

Tests

Test creating single user chat

  1. Tap the global create button
  2. Select “Start chat”
  3. Pick a single user
  4. Verify you are navigated to the chat

Test creating single user chat with new account

  1. Tap the global create button
  2. Select “Start chat”
  3. Pick a single user
  4. Verify you are navigated to the chat

Test existing Group DM looks and behaves normal in staging

  1. Create a Group DM (on production) (note the reportID for access later)
  2. Log back into same account (on staging)
  3. Access the Group DM
  4. Verify the avatars and title look correct (multiple avatars)
  5. Tap the + icon
  6. Choose Split bill option and complete the split for a “Manual” request
  7. Verify that the splits are created on each participant’s chat

Test creating new Group Chat

  1. Tap the global create button
  2. Select “Start chat”
  3. Choose two users to add via “Add to group” button
  4. Choose another user to add by entering email (new account)
  5. Press “Next”
  6. Verify the “Group” confirm page displays the members
  7. Verify a member can be de-selected
  8. Verify the current user has a label that says “Admin”
  9. Tap “Start group”
  10. Verify you are navigated to the chat
  11. Verify the group chat name in the header includes the current user
  12. Verify there is a single avatar vs. the multiple avatars that Group DMs have

Create new group from existing DM members

  1. Create a Group DM (on production) (note the reportID for access later)
  2. Log back into same account (on staging)
  3. Tap the global create button
  4. Select “Start chat”
  5. Select the same members with existing DM
  6. Verify a new chat is created.
  7. Repeat and verify that you can create multiple chats with these same users.

Verify that users only see Group Chats when a comment appears

  1. As User A create a Group Chat between User B and User C
  2. As User B verify that the chat is not visible in the LHN
  3. As User C verify the chat is not visible
  4. As User A leave a comment
  5. As User B and C verify that the chat is now visible and the comment from User A displayed

Verify Global Create split creates new Group Chat

  1. Tap the global create button
  2. Select “Request money”
  3. Choose manual
  4. Enter amount and tap “Next”
  5. Select multiple users to split with and tap “Next”
  6. Tap “Split $nn.nn”
  7. Verify that a Group Chat is created and the split preview lands there
  8. Verify that the splits appear on each individual 1:1 chat for the participants
  • Verify that no errors appear in the JS console

Offline tests

Same as tests

QA Steps

None

  • Verify that no errors appear in the JS console

PR Author Checklist

  • I linked the correct issue in the ### Fixed Issues section above
  • I wrote clear testing steps that cover the changes made in this PR
    • I added steps for local testing in the Tests section
    • I added steps for the expected offline behavior in the Offline steps section
    • I added steps for Staging and/or Production testing in the QA steps section
    • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
    • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
    • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
  • I included screenshots or videos for tests on all platforms
  • I ran the tests on all platforms & verified they passed on:
    • Android / native
    • Android / Chrome
    • iOS / native
    • iOS / Safari
    • MacOS / Chrome / Safari
    • MacOS / Desktop
  • I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
  • I followed proper code patterns (see Reviewing the code)
    • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
    • I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
    • I verified that comments were added to code that is not self explanatory
    • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
    • I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
      • If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:
    • I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
    • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
    • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
    • I verified the JSDocs style guidelines (in STYLE.md) were followed
  • If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
  • I followed the guidelines as stated in the Review Guidelines
  • I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
  • I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
  • I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
  • I verified that if a function's arguments changed that all usages have also been updated correctly
  • If a new component is created I verified that:
    • A similar component doesn't exist in the codebase
    • All props are defined accurately and each prop has a /** comment above it */
    • The file is named correctly
    • The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
    • The only data being stored in the state is data necessary for rendering and nothing else
    • If we are not using the full Onyx data that we loaded, I've added the proper selector in order to ensure the component only re-renders when the data it is using changes
    • For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
    • Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
    • All JSX used for rendering exists in the render method
    • The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
  • If any new file was added I verified that:
    • The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
  • If a new CSS style is added I verified that:
    • A similar style doesn't already exist
    • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG))
  • If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
  • If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
  • If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
  • If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
  • If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
  • I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

Web image image image image

Copy link
Contributor

@marcaaron marcaaron left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking super good so far! Left some thoughts and a few tips. Overall moving in a great direction. Thanks very much! 🙇

@@ -1142,6 +1142,9 @@ export default {
roomDescriptionOptional: 'Descripción de la sala de chat (opcional)',
explainerText: 'Establece una descripción personalizada para la sala de chat.',
},
groupConfirmPage: {
groupName: 'Nombre del grupo',
},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note: If we didn't yet - we should get these final approved by someone in the español channel (can wait for later)

src/libs/ReportUtils.ts Show resolved Hide resolved
src/libs/actions/Report.ts Outdated Show resolved Hide resolved
src/libs/actions/Report.ts Outdated Show resolved Hide resolved
src/pages/NewChatConfirmPage.tsx Outdated Show resolved Hide resolved
src/pages/NewChatConfirmPage.tsx Outdated Show resolved Hide resolved
src/pages/NewChatConfirmPage.tsx Outdated Show resolved Hide resolved
src/pages/NewChatConfirmPage.tsx Show resolved Hide resolved
src/pages/NewChatPage.tsx Outdated Show resolved Hide resolved
@waterim
Copy link
Contributor Author

waterim commented Mar 4, 2024

@marcaaron I have a question reagarding this part:
image
Here you are showing that we have "chatType", "reportName" and "groupChatAdminLogins" as parameters.
But we don't have them all in our OpenReportParams type:
image
image

Should I just add all those params like this?
image

Because as I can see we already have reportName and chatType in OptimisticData in this request and Im confused a bit :D
Do I need to add it additionally in a new request design?
Or just to update reportName, chatType and add groupChatAdminLogins to OptimisticData which we are sending?

@marcaaron
Copy link
Contributor

Yes good question. The OpenReport API request is very generic and can be used to create a few different report types. I would continue down this path for now and add whatever is missing as optionals. We will need:

optimisticAccountIDList: string,
chatType: string,
groupChatAdminLogins: string,
optimisticAccountIDList: string,

Later we can add something to handle the avatar - but those should be enough for this PR.

And you will basically want some check like:

if (chatType == 'group') {
    paramters.chatType = 'group';
    parameters.groupChatAdminLogins = logins.join();
    paramters.optimisticAccountIDList = accountIDList.join();
    parameters.reportName ? reportName : '' // pass the empty string here
}

@marcaaron
Copy link
Contributor

marcaaron commented Mar 5, 2024

If there is some fancy way to do that with typescript and make it clear that only a "group chat" should have these additional params that would also be acceptable (but no need to prioritize this).

@waterim
Copy link
Contributor Author

waterim commented Mar 5, 2024

@marcaaron Updated the code, seems to work fine.
As I understand one more thing will be to update participantAccountIDs to participants, right?

(I know that tests are failing, thats ES translations)

@marcaaron
Copy link
Contributor

As I understand one more thing will be to update participantAccountIDs to participants, right?

Yes, this is a little bit of a tricky part because we want:

  • Any chat that is not a Group Chat to keep using the existing logic (the backend is still needing to be migrated for these).
  • If it's a Group Chat then it should only use participants object and never use participantAccountIDs or visibleChatMemberAccountIDs.

Basically, we are going to:

  • Have both Group Chats and other kinds of chats exist side by side for some time.
  • Ensure we have correct participants data being sent for the other kinds of chats in the backend (already should work for Group Chats)
  • Deprecate participantAccountIDs and visibleChatMemberAccountIDs in the front end
  • Remove them from the backend code after force upgrading everyone to the new participants object.

I suspect this migration will take a bit longer than the Group Chats feature itself and we are targeting end of May for release so that's why it's happening in this order 🙃

But open to any thoughts on it too. Let me know if you run into any issues or confusing things.

@waterim
Copy link
Contributor Author

waterim commented Mar 5, 2024

@marcaaron Okay, get it, I can do a conditional call for group chats for now with "participants" field.
As I understand we have a separate ticket to handle all places and here I can just modify this one.
I think everything for group chats is done, except participants(feel free to comment if I missed something) and after I will add splits too

@waterim
Copy link
Contributor Author

waterim commented Mar 6, 2024

@marcaaron Was able to create with such a response:
image
But some issue that I have button "join" on the page:
image

Looks like Im not an admin of this group chat, but send participants correctly and GroupChatAdminLogins too

GroupChatAdminLogins is there:
image

@marcaaron
Copy link
Contributor

@marcaaron Was able to create with such a response:

Nice!

But some issue that I have button "join" on the page:

👍 We want that "Join" button to not exist if you are a participant. It is showing because the notificationPreferences are hidden see here:

const canJoinOrLeave = !isSelfDM && (isChatThread || isUserCreatedPolicyRoom || canLeaveRoom);
const canJoin = canJoinOrLeave && !isWhisperAction && props.report.notificationPreference === CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN;
const canLeave = canJoinOrLeave && ((isChatThread && props.report.notificationPreference.length) || isUserCreatedPolicyRoom || canLeaveRoom);

Easiest would be to add a check like:

const canJoinOrLeave = !isSelfDM && !isGroupChat && (isChatThread || isUserCreatedPolicyRoom || canLeaveRoom);

Nobody can "Join" a Group Chat like this. Have to be invited by someone for now.

Looks like Im not an admin of this group chat

I think you are the admin, we just don't show it anywhere on the members page yet. So, it's a new thing to add. But, let me know if I didn't understand your question! Thanks!

2024-03-06_15-47-47

@waterim
Copy link
Contributor Author

waterim commented Mar 7, 2024

@marcaaron Looks like added everything, but needs to be checked carefully, because could miss something, doc is not really detailed, but hopefully everything is here :)

@waterim
Copy link
Contributor Author

waterim commented Mar 7, 2024

Ah, okay, OptionsSelector was deprecated, rewriting to SelectionList

@waterim
Copy link
Contributor Author

waterim commented Mar 7, 2024

Updated and resolved conflicts

src/libs/actions/Report.ts Outdated Show resolved Hide resolved
src/libs/actions/Report.ts Outdated Show resolved Hide resolved
@marcaaron
Copy link
Contributor

Ok, thanks for the investigation there (did not have a chance as I discovered the bug later in my day).

I will try to find the answer to this. We have @aldo-expensify working on a PR related to OpenReport and it seems like it would fix the problem.

@marcaaron
Copy link
Contributor

Ah ha actually - the problem is that everyone is "hidden" until we leave a comment on the chat. Of course, apologies for not catching that sooner. My head was on backwards yesterday.

This is expected as the visibleChatMemberAccountIDs would be all the users who have hidden: true. If we can use the participants then they should always be displayed for the case of a Group Chat. I think we can fix it by using this field for the members, but no need for right now.

Optimistic chat report should have:

{hidden: true} for all the users

Real chat report returned should have:

{hidden: true} for all the users

When someone leaves a comment it will end up as

{hidden: false}

I think there is nothing we need to do here for now. We will update this to use participants only eventually. The optimistic report should have {hidden: true} as well. But we don't need to block on that. I'm going to give this a merge and see how the QA goes. 🤞

Thanks everyone!

@marcaaron marcaaron self-requested a review March 28, 2024 18:31
@marcaaron marcaaron merged commit 2b96626 into Expensify:main Mar 28, 2024
16 checks passed
@melvin-bot melvin-bot bot added the Emergency label Mar 28, 2024
Copy link

melvin-bot bot commented Mar 28, 2024

@marcaaron looks like this was merged without a test passing. Please add a note explaining why this was done and remove the Emergency label if this is not an emergency.

@OSBotify
Copy link
Contributor

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

@marcaaron
Copy link
Contributor

Not emergency. Looks like tests have passed.

@OSBotify
Copy link
Contributor

🚀 Deployed to staging by https://github.com/marcaaron in version: 1.4.58-0 🚀

platform result
🤖 android 🤖 success ✅
🖥 desktop 🖥 success ✅
🍎 iOS 🍎 success ✅
🕸 web 🕸 success ✅

@stitesExpensify
Copy link
Contributor

👋 I think that this deploy blocker is probably a result of this PR. Would you mind taking a look please?

@waterim
Copy link
Contributor Author

waterim commented Mar 29, 2024

@stitesExpensify It was not a scope of this issue, should not be a blocker
Cc: @marcaaron

@marcochavezf
Copy link
Contributor

Also seems this issue is coming from this PR, but I don't think it should be a deploy blocker.

@OSBotify
Copy link
Contributor

OSBotify commented Apr 2, 2024

🚀 Deployed to production by https://github.com/Beamanator in version: 1.4.58-8 🚀

platform result
🤖 android 🤖 success ✅
🖥 desktop 🖥 success ✅
🍎 iOS 🍎 success ✅
🕸 web 🕸 success ✅

Comment on lines +199 to +207
let newSelectedOptions;
if (newGroupDraft?.participants) {
const selectedParticipants = newGroupDraft.participants.filter((participant) => participant.accountID !== personalData.accountID);
newSelectedOptions = selectedParticipants.map((participant): OptionData => {
const baseOption = OptionsListUtils.getParticipantsOption({accountID: participant.accountID, login: participant.login, reportID: ''}, personalDetails);
return {...baseOption, reportID: baseOption.reportID ?? ''};
});
setSelectedOptions(newSelectedOptions);
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This overwrites the selected participants with the draft values everytime the options are re-rendered making it impossible to control the selection properly. Caused issue #39295. FIx #39312

onSelectRow={unselectOption}
showConfirmButton={selectedOptions.length > 1}
confirmButtonText={translate('newChatPage.startGroup')}
onConfirm={createGroup}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We missed adding a condition here to check if anything is selected before calling onConfirm - this caused an issue where CMD+enter can still proceed past the step.

@@ -3649,6 +3693,15 @@ function buildOptimisticChatReport(
parentReportID = '',
description = '',
): OptimisticChatReport {
const participants = participantList.reduce((reportParticipants: Participants, accountID: number) => {
const participant: ReportParticipant = {
hidden: false,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is causing issue #41832, for the transaction threads this needs to be true to be consistent with BE.

@@ -1343,7 +1347,7 @@ export default {
},
newChatPage: {
createChat: 'Crear chat',
createGroup: 'Crear grupo',
startGroup: 'Grupo de inicio',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This translation is wrong. I search in slack and I could not find any mention of this particular string, so I think it was not reviewed by anyone and if that's correct it means that @waterim you checked this checklist item without actually doing it:

If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW changed this here #45342

Comment on lines +297 to +299
confirmButtonText={selectedOptions.length > 1 ? translate('common.next') : translate('newChatPage.createChat')}
textInputAlert={isOffline ? [`${translate('common.youAppearToBeOffline')} ${translate('search.resultsAreLimited')}`, {isTranslated: true}] : ''}
onConfirmSelection={createGroup}
onConfirmSelection={selectedOptions.length > 1 ? navigateToConfirmPage : createChat}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should have removed the requirement that a group chat needs more than 1 other participant to be created because this requirement was only applicable in the NewChatPage and could be skipped in NewChatConfirmPage causing inconsistency. Also because this was not really a requirement after all.

return options;
}, [allPersonalDetails, newGroupDraft?.participants]);

const groupName = ReportUtils.getGroupChatName(participantAccountIDs ?? []);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Coming from this issue #46502, this is a case that we might miss when testing/implementing this issue. For the details, we check here #46502 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.