Block chronos@, receipts@ and concierge@ from Split Bill and Request Money

[Santhosh-Sellavel]

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

---

Action Performed:

1. New Request/split bill
2. Enter the amount
3. In search enter the full email as "[email protected]" || "[email protected]"
4. From search you can find Concierge and Chronos in search results.

#4413 (comment)
We should also block '[email protected]'.

Note: Chronus is shown in results only for the first time. if entered in lower case it will not show in results refer to attachments

From the second time, Chronus will show in Recents will not be able to reproduce.
There is an already issue for that raised here #4411

Expected Result:

We should not be able to request from Concierge or Chronos

Actual Result:

Concierge

Request-money.from.concierge.mov

Chronus:

Workaround:

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

Platform:

Where is this issue occurring?

• Web
• iOS
• Android
• Desktop App
• Mobile Web

Version Number:
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
Expensify/Expensify Issue URL:

View all open jobs on Upwork

[MelvinBot]

Triggered auto assignment to @sonialiap (AutoAssignerTriage), see https://stackoverflow.com/c/expensify/questions/4749 for more details.

[Santhosh-Sellavel]

Proposal

In OptionUtilsList add new method isExcludedIOUUsers we can change it to

And uses from both IOUParticipantsRequest.js & IOUParticipantsSplit.js as below,

[MelvinBot]

Triggered auto assignment to @pecanoro (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

[sonialiap]

We should probably also block [email protected]

[Santhosh-Sellavel]

@pecanoro proposed changes are available in drafted PR.

@sonialiap excluded [email protected]

[MelvinBot]

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

[MelvinBot]

Triggered auto assignment to @stephanieelliott (External), see https://stackoverflow.com/c/expensify/questions/8582 for more details.

[pecanoro]

Anyways, regardless of the front end, maybe we should open an issue to block this in the back-end as well. I will open an issue for it in our other repos.

[Santhosh-Sellavel]

@pecanoro Yes, that would be even safer.

[Santhosh-Sellavel]

Updated Proposal

Following are the changes, we need to make to restrict this in client-side search.

1. Adding [email protected] to the CONST File.

2. Function to check whether user is excluded from IOU

3. Using the function in respective IOU confirmation pages,

@pecanoro If you are okay with the proposal, I'll wrap my PR work.
Thanks!

[stephanieelliott]

Posted to Upwork: https://www.upwork.com/jobs/~013379d6a3621d716e

[marcaaron]

@stephanieelliott Let's hire @Santhosh-Sellavel please, thanks!

[stephanieelliott]

Hey @Santhosh-Sellavel can you post a proposal to the job in Upwork so we can hire you? https://www.upwork.com/jobs/~013379d6a3621d716e

[Santhosh-Sellavel]

Applied @stephanieelliott

[stephanieelliott]

Great, gotcha @Santhosh-Sellavel!

[MelvinBot]

Triggered auto assignment to @mallenexpensify (External), see https://stackoverflow.com/c/expensify/questions/8582 for more details.

[stephanieelliott]

I'm taking an extended OOO, re-applied the External label to get another CM to take this the rest of the way, thanks @mallenexpensify!

[Christinadobrzyn]

I see the PR related to this issue is here. Still being reviewed.

[marcaaron]

Hit a minor snag on this issue since there is another PR that adds a handful of other "expensify emails" and it may change the solution somewhat as there are other emails that should also be blocked.

It also looks like we should already be preventing emails like [email protected] in OptionsListUtils. I tested this on main and the logic works fine. So, overall I think the original solution presented here needs to change.

App/src/libs/OptionsListUtils.js

Lines 415 to 425 in 95bf36d

	if (excludeConcierge) {
	loginOptionsToExclude.push({login: CONST.EMAIL.CONCIERGE});
	}
	if (excludeChronos) {
	loginOptionsToExclude.push({login: CONST.EMAIL.CHRONOS});
	}
	if (excludeReceipts) {
	loginOptionsToExclude.push({login: CONST.EMAIL.RECEIPTS});
	}

@pecanoro just to double check we probably do not want to be able to create IOUs with any of these EXPENSIFY_EMAILS ?

If so, then it is probably best to:

1. Make sure the exclude logic added in Hide automated accounts from Recent sections of Split Money/Request Money #4648 is actually working (it seems to work fine - but @Santhosh-Sellavel noticed it does not work if we use improper case like [email protected])
2. Also create an option to do all the emails excludeExpensifyEmails instead of a flag for each like we are doing here

App/src/libs/OptionsListUtils.js

Lines 325 to 327 in 95bf36d

	excludeConcierge = false,
	excludeChronos = false,
	excludeReceipts = false,

@Jag96 what do you think of this solution? I'm unsure if we still want to keep the individual flags for excluding a specific participant with so many to exclude. I think we can just get rid of them as the only place where these emails are excluded are in the IOU selectors?

[Jag96]

If we're always going to apply the same logic for all of those accounts, then I think it's fine to use excludeExpensifyEmails instead of having individual values. I think this is the only place we have one value that isn't the same as the others, so we'd have to handle that case right?

[marcaaron]

Ah nice catch thanks @Jag96 I missed that we were passing true there. I think then we can just remove the more specific handling for concierge@ and chronos@ (seems their defaults were false anyway if not specified).

Sorry for the back and forth here @Santhosh-Sellavel but just want to make sure we have a solid path forward and aren't introducing a solution we don't need. I know it's not the original proposal we discussed, but are you OK to make these changes?

[parasharrajat]

Maybe an option allowedExpensifyEmails as array could be alternative.

[marcaaron]

Maybe an option allowedExpensifyEmails as array could be alternative.

Possibly, but I think in most cases we want to allow them. It's less common (so far) to want to exclude them (we only want to exclude all emails in 2 places and a single email in 1 place).

We'd have to do something like

allowedExpensifyEmails: _.without(EXPENSIFY_EMAILS, '[email protected]')

which is less intuitive than

In IOU components...

excludeExpensifyLogins: true,

and

In NewChatPage...

excludeReceipts: true,

That said, it does seem kind of specific to have excludeReceipts for a single usage when we could just as easily pass a block list of emails that should be excluded. Those examples would change to:

loginsToExclude: EXPENSIFY_EMAILS,

loginsToExclude: [CONST.EMAIL.RECEIPTS],

[Santhosh-Sellavel]

Sure @marcaaron, I'll make the changes. And raise a new PR!

[Santhosh-Sellavel]

@marcaaron whatever we discussed here is captured in this draft PR #4821, also there are some additional emails as well.

[marcaaron]

Ok well there is no sense in having two separate issues handling the same thing. @AndrewGable @deetergp it would be good if there was some way to prevent contributors from working on the same issues in the future. Seeing as @Santhosh-Sellavel opened the issue first I suggest that we close this.

@mallenexpensify I think we should just pay @Santhosh-Sellavel and close this out.

[Santhosh-Sellavel]

@mallenexpensify Since this issue already closed. Kindly end the contract when you have time without any negative feedbacks. Thanks!

[mallenexpensify]

Cancelled in Upwork, left positive feedback for you @Santhosh-Sellavel