Username != user email in sandboxes

[dschach]

https://github.com/trailheadapps/apex-recipes/blob/394e33592c7a9167587bfa4dae04ef2e46e09f95/force-app/main/default/classes/Trigger%20Recipes/MetadataTriggerService.cls#L49

I'm curious how to address this, since the bypass will fail if we compare running user email to username (since username has a suffix, and SOME user emails will have had that suffix removed).

[github-actions[bot]]

Welcome! 👋

Thank you for posting this issue. 🙇🏼‍♂️ We will come back to you latest within the next 48h (working days). Stay tuned!

[msrivastav13]

This is an example we have shown with an assumption that emails are also used as usernames for users in the org!!

If this is not true for your org feel free to simply user Email directly to compare or any other unique Identifier for your user. You might need to use UserInfo.getUserEmail() if you use email for comparison.

Hope that helps!

[dschach]

This is a good opportunity to show best-practices, which means that code should work in any org. Can you use startswith() somewhere, to at least make sure that the username or email matches?

[docbill]

Even starts with is not a good solution.

For example, I will often make my e-mail address in a sandbox indicate the sandbox name like:

@.***

While my username would often be:

@.***

The reason being is the . syntax is applied automatically by salesforce. But often, salesforce e-mails do not clearly indicate which sandbox they are from. If I want to avoid panic from thinking production is down, I want something that can easily be identified in the e-mail headers.

At RedHat we actually have multiple salesforce production instances. So often times even the production usernames maynot be their e-mail address.

Regards,

Bill

On Mon, Jul 18, 2022 at 1:19 AM David Schach @.***> wrote:

This is a good opportunity to show best-practices, which means that code should work in any org. Can you use startswith() somewhere, to at least make sure that the username or email matches?

— Reply to this email directly, view it on GitHub https://github.com/trailheadapps/apex-recipes/issues/336#issuecomment-1186778496, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYFYWAN6BDK7JESWVBXY2TVUTSOJANCNFSM53P4OTFQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

--

Bill C Riemers, PhD, CSM, CSD, A-CSD, SALESFORCE CPD I, SALESFORCE CDL&DA

Principal Software Engineer

Red Hat Canada Ltd https://www.redhat.com/

Enterprise Sales + Services (ESSA) https://red.ht/sighttps://patents.justia.com/inventor/bill-c-riemers

[docbill]

Sometimes these autofilters of private information are a pain:

My production username might be:

briemers AT redhat.com.gss

Indicating it in RedHat's gss instance. My e-mail address might be set to:

briemers+gss AT redhat.com

Because I need something to filter email.

A sandbox might have a username and e-mail set respectively as:

briemers AT redhat.com.gss.mysandbox

briemers + gss.mysandbox AT redhat.com

Different users use different conventions for what they set their e-mail to. And different organizations use different ways to modify user names to be unique across production orgs.

It would be hard to compare that even with well written regular expressions.

On Mon, Jul 18, 2022 at 10:16 AM Bill C Riemers @.***> wrote:

Even starts with is not a good solution.

For example, I will often make my e-mail address in a sandbox indicate the sandbox name like:

@.***

While my username would often be:

@.***

The reason being is the . syntax is applied automatically by salesforce. But often, salesforce e-mails do not clearly indicate which sandbox they are from. If I want to avoid panic from thinking production is down, I want something that can easily be identified in the e-mail headers.

At RedHat we actually have multiple salesforce production instances. So often times even the production usernames maynot be their e-mail address.

Regards,

Bill

On Mon, Jul 18, 2022 at 1:19 AM David Schach @.***> wrote:

This is a good opportunity to show best-practices, which means that code should work in any org. Can you use startswith() somewhere, to at least make sure that the username or email matches?

— Reply to this email directly, view it on GitHub < https://github.com/trailheadapps/apex-recipes/issues/336#issuecomment-1186778496 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAYFYWAN6BDK7JESWVBXY2TVUTSOJANCNFSM53P4OTFQ

. You are receiving this because you are subscribed to this thread.Message ID: @.***>

--

Bill C Riemers, PhD, CSM, CSD, A-CSD, SALESFORCE CPD I, SALESFORCE CDL&DA

Principal Software Engineer

Red Hat Canada Ltd https://www.redhat.com/

Enterprise Sales + Services (ESSA) https://red.ht/sighttps://patents.justia.com/inventor/bill-c-riemers

— Reply to this email directly, view it on GitHub https://github.com/trailheadapps/apex-recipes/issues/336#issuecomment-1187547285, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYFYWC7SJAUN22FJEYRLKLVUVRM5ANCNFSM53P4OTFQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

--

Bill C Riemers, PhD, CSM, CSD, A-CSD, SALESFORCE CPD I, SALESFORCE CDL&DA

Principal Software Engineer

Red Hat Canada Ltd https://www.redhat.com/

Enterprise Sales + Services (ESSA) https://red.ht/sighttps://patents.justia.com/inventor/bill-c-riemers

[codefriar]

Team,

This 'feature' was originally designed and built on the fly in response to a question on the live stream.

It is not fully baked for production use. It is however, a useful learning and teaching exercise. While I stand by Apex-Recipes, it is not, and never was designed to be something end-developers should adopt without adaptation.

Because of this, I think @dschach's point is entirely valid, but beside-the-point for this repo. For an adoption ready version of metadata driven triggers, look to ASL. It's early in the development cycle, but aims to be a production ready, batteries included set of opinionated 'jigs' that help developers rapidly and easily tackle common tasks.

[msrivastav13]

@dschach, I think every org is unique, and this repo aims not to build code that addresses the needs of every org. I will let the sample apps lead @pozil share his views on this.

[pozil]

I concur with my colleagues. Apex Recipes are samples that are not meant to be deployed to production as-is or fit all needs. If we were building something generic and fully configurable, it would make the code harder to approach for learners.