This request doesn't describe a root problem (see Describing Root Problems), but we can only accept feature requests which completely describe root problems. See Contributing Feature Requests for more.

In particular, it doesn't have enough information to let us consider workarounds or different solutions to whatever the issue is, or offer similar but simpler solutions which may be good enough even if they aren't complete. It also doesn't have enough information for us to generalize the problem and consider larger solutions which can solve this problem and other problems at the same time. There is only enough information to solve it in exactly one way, by implementing the requested feature exactly.

We don't accept feature requests like this for many reasons, but a major reason is that we can not maintain them. If we do not know why we implemented a feature, we can not reason about it in the future when the product changes or other users ask us for related features. If we implement this feature exactly as described today without any understanding of why we're doing it and someone files a request to change the behavior tomorrow, we can't know if the change is harmless or completely breaks the feature for you. If you describe a problem you want to solve instead, we can reason about whether whether future changes disrupt Phabricator's ability to solve that problem.

See also T8227 for discussion of why features which require new configuration options face a very high barrier to reaching the upstream.

To move forward, completely describe the problem you're facing. Otherwise, we'll close this request in a few days (but you can always file a new request later).

Sorry about that. I have added more details to the description.

Please read and follow the guidelines in Contributing Feature Requests and Describing Root Problems. These are required for any request. Specifically this request still omits a root problem and seems to be just a design / ux suggestion. Given we have thousands of tasks and 2 developers, we don't take feature requests that don't have a root problem, we'd never be able to prioritize them.

Likewise if this only might cause confusion, but has not actually caused confusion yet, it's a hypothetical problem (see Hypotheticals). We don't accept requests to address hypothetical problems because they often never actually occur.

Phabricator has worked like this for many years with no reports of actual confusion, so what information we have available suggests this is not actually confusing in practice, or at least that very few users are confused. If this is only confusing to, say, 1 in 20,000 users, we might make the product worse overall by implementing an option for it. If you imagine a version of Phabricator with 20,000 setup options to address 20,000 rare issues experienced by only a tiny number of users, it would clearly be worse than what we have today.

If this is actually significantly confusing in practice, the particular nature of the confusion is important: for example, are users actually confused about who is sending them mail? Or is a system, like a mail client's address book, confused about sender identity? A deeper understanding of the actual problem will allow us to consider solutions like T1837, or rewriting mail to be more clear, or improving documentation around client-side mail routing rules, or whatever else.

Sorry for not getting back sooner.

I agree that this is just a (minor) UI issue, and I can easily modify in my local branch to enable this. If you think this is not something that worth upstream, I'm happy to close this and implement workaround in my local branch.

Set mail sender as custom name to edit file externals/phpmailer/class.phpmailer.php, change $this->FromName = $name; to $this->FromName = 'CodeReview';.