App: [$250] [HOLD for payment 2024-04-09] [CRITICAL] [Groups] Frontend (Part 1): Create Group Chats + Splits. Deprecate Group DM creation. Support viewing both Group DMs and Group Chats.

@waterim apologies, I must amend something that I’ve said WRT to the participant accountIDs as I did not notice until now 😅

(not shown, but we can also call it with an accountIDList as in this example - more on this below)

It’s true that we can call the API with an accountIDList - but I think we actually need to create a new request param like optimisticAccountIDList so we can check if any have changed. I’m working on this backend change now so it will be ready for us to test when we need it.

Hello, Im Artem from Callstack and already working on this!

All set. TY!

Noting that @marcaaron and I discussed this 1:1 and decided that there should be no regression penalties here. Marc flagged that @s77rt has gone above and beyond to do a great job working on this project, and any missed cases are not indicative of mistakes or anything like that.

So we’re going to pay out the full $500 to @s77rt for this one via Upwork.

Done! Thanks for your help on this one.

@marcaaron i think Wednesday is a most likely possible day for an open PR. i was busy on Friday, today got back to the task, resolving last your comment and would be able to proceed with creation!

@marcaaron Created a draft with ongoing changes, working on the create flow

After I merged main I found a weird bug related to new chat creation page, probably the issue with OptionsSelector itself. The issue is with selecting and deselecting people.

Here is a video with the bug from https://staging.new.expensify.com/new/chat

https://github.com/Expensify/App/assets/39777589/ffb6b74e-f32b-4a77-a1ca-88d52fcfb5c6

Do I need to report it or ticket already exists for this? @marcaaron @shawnborton

Let me see if I can get @dubielzyk-expensify to answer this one. I would guess we want these to be consistent with whatever we are doing now. They are SVGs so resizing should be no problem as they are vector graphics? Maybe I did not fully understand the question.

@waterim The .svgs are vector graphics so they scale nicely to 80x80. It’s only .pngs we need to export larger assets for. So yeah, you should be able to use the svg assets fine 😃

cc @Expensify/design

Maybe I should create a draft with ongoing changes to understand if Im on the right way

That sounds perfect. It will be easier to discuss some of these changes in the context of a PR and I can point you directly to the places in the code we need to update.

For now, I’ll answer your questions so far.

memberRoles and reportName, but where to pass those fields

When we are creating a Group Chat we will call the API with these parameters and some others.

(not shown, but we can also call it with an accountIDList as in this example - more on this below)

Existing method where we call this API is here (use staging.expensify.com or expensify.com for testing).

The design has changed a bit. For the API we need to just take any “admins” and make sure they are in the list of groupChatAdminLogins.

API would then return something like this for the report object:

{
            "onyxMethod": "merge",
            "key": "report_3166052379363217",
            "value": {
                "reportID": "3166052379363217",
                "reportName": "Testing",
                "type": "chat",
                "chatType": "group",
                "ownerAccountID": 0,
                "managerID": 0,
                "policyID": "_FAKE_",
                "participants": {
                    "17356": {
                        "hidden": true,
                        "role": "admin"
                    },
                    "17357": {
                        "hidden": true,
                        "role": "member"
                    },
                    "17358": {
                        "hidden": true,
                        "role": "member"
                    }
                },
                "participantAccountIDs": [
                    17356,
                    17358,
                    17357
                ],
                "visibleChatMemberAccountIDs": [],
                "isPinned": false,
                "lastReadTime": null,
                "lastMentionedTime": null,
                "lastReadSequenceNumber": 0,
                "lastVisibleActionCreated": "2024-02-28 03:23:15.981",
                "lastVisibleActionLastModified": "2024-02-28 03:23:15.981",
                "lastMessageText": "",
                "lastActorAccountID": 0,
                "notificationPreference": "hidden",
                "stateNum": 0,
                "statusNum": 0,
                "oldPolicyName": "",
                "visibility": null,
                "isOwnPolicyExpenseChat": false,
                "lastMessageHtml": "",
                "iouReportID": null,
                "hasOutstandingChildRequest": false,
                "policyName": null,
                "hasParentAccess": null,
                "parentReportID": null,
                "parentReportActionID": null,
                "writeCapability": "all",
                "description": "",
                "isDeletedParentAction": null,
                "reportFields": null,
                "total": 0,
                "unheldTotal": 0,
                "currency": "USD",
                "submitterPayPalMeAddress": "",
                "chatReportID": null,
                "isWaitingOnBankAccount": false,
                "nonReimbursableTotal": 0,
                "isCancelledIOU": false
            }
        }

So we need our optimistic report here to have roughly the same participants object.

And regarding this part Finally, the optimistic report is passed here to be created in the server. We must also pass the groupChatAdminLogins. .

This was not worded correctly. But anyone who is an “admin” should get passed to groupChatAdminsLogins (for now it’s only the report creator - so not too much to worry about for this PR).

The trickiest part for this will be updating the participants accountID when we do not yet have them. We do something like this:

https://github.com/Expensify/App/blob/98461f987e08e1ee977bd60f4974513b84b3c93d/src/libs/actions/Report.ts#L736-L748

Which can also have a generated accountID for a user that may or may not exist yet:

https://github.com/Expensify/App/blob/98461f987e08e1ee977bd60f4974513b84b3c93d/src/libs/PersonalDetailsUtils.ts#L65-L76

So, this needs to be referenced in the participants object. Then the API should remove any of these “fake users”. Sounds complicated, but we can focus on users that exist for now and figure a few of the details out as we go if that works for you.

I think hopefully seeing the API request/response for this part will fill in some of the missing pieces. But please do not hesitate to let me know if anything else is unclear. Thanks very much! 🙇

My update: working on this, hopefully first half of the next week will finish with initial version for reviews

@waterim is taking this one on https://expensify.slack.com/archives/C03UK30EA1Z/p1707785405223319