Welcome in Phorge and long life to FreeBSD! You are now in the family of Trusted Contributors and so you can create Tasks.

Right. I mentioned that in at least one answer. I'm closing since you resolved :)

In T15719#15280, @avivey wrote:

I'm left wondering when a "list-unsubscribe" header is appropriate - looks like anything that would need it will also need the one-click?

In T15719#15280, @avivey wrote:

This suggests to me that there isn't a third category - everything is either promotional or transactional.

I'd argue that none of our emails are "marketing" or "promotional" (or "commercial"), even if it's hard to claim they are "transactional".
But as long as 98%[1] of the users agree that our mails aren't commercial, we don't need the one-click solution.

Maybe we can wontfix this, and try other more modern approaches like flatpak. Example:

The new font family styles does look not very nice on macOS, look at the bold texts...

maybe

if ($this->getIsNewObject() || $xaction->getTransactionType == ...)

?
Then it only needs to be tested in the one case, and we can avoid code creeping from Differential here.

In D25517#14977, @valerio.bozzolan wrote:

// TODO: Once everything is on EditEngine, just use getIsNewObject()

So maybe this? but I'm not bold enough:

Before and after applying D25525:

Do all messages require one-click unsubscribe?
No. One-click unsubscribe is required only for marketing and promotional messages. Transactional messages are excluded from this requirement. ...

In T15719#15272, @avivey wrote:

1. Would adding List-Unsubscribe: https://we.phorge.it/settings/panel/emailpreferences/ header be enough to solve this?

Glad you got it working and happy to help!

This was precisely what I was looking for, thank you. Turns out auth was failing -- same UN/PW as for my mail clients, so.. ..looking into it, my MTA was accepting PLAIN auth, but not LOGIN auth. That's resolved now.

In T15719#15276, @Dzahn wrote:

@phab1004:/srv/phab/phabricator/bin# ./mail volume

Killed

In T15719#15272, @avivey wrote:

using bin/mail volume, to see if they need to worry about this. It just collects all mails created in the last N days and counts them by user.

This is promising, from the Email sender guidelines FAQ:

Re: 1), the doc makes it sound like not, but I'm not entirely sure.

1. Would adding List-Unsubscribe: https://we.phorge.it/settings/panel/emailpreferences/ header be enough to solve this?

In D25500#15024, @aklapper wrote:

and thus remove the only newly added call which returned null in src/applications/meta/query/PhabricatorApplicationApplicationTransactionQuery.php)

In D25500#15027, @aklapper wrote:

Maybe we can return ClassName::class - that is supported since PHP 5.5

there's a lot more code to update in random *Query.php classes defining getQueryApplicationClass() functions, in a separate future patch

What issues did you run into when using ./bin/mail send-test?

It makes sense thanks. Minor note:

Right. Sorry, my previous comment was very misleading!

In what case, a class can be installed "for the viewer", but generally uninstalled?

double-accept

Sorry for the confusion. I mean that the /mail/ page is the Mail Dashboard that allows to see both Inbox and Outbox (visible from the left sidebar menu). For example this is the exact Outbox sub-page:

Maybe we can return ClassName::class - that is supported since PHP 5.5

Note to myself: Makes sense; there's a lot more code to update in random *Query.php classes defining getQueryApplicationClass() functions, in a separate future patch

Revert turning getQueryApplicationClass() abstract in the parent class src/applications/transactions/query/PhabricatorApplicationTransactionQuery.php and make it return null again (and thus remove the only newly added call which returned null in src/applications/meta/query/PhabricatorApplicationApplicationTransactionQuery.php); also return ::class as proposed by Valerio

Fix D25501#14443: Do not show an "Query overheated" error when the user is anonymous and the application has been uninstalled

Once I get back to working with that instance, I suppose I'll go to my inbox -- where (you seem to be implying) it will show me errors from when the system sent me the initial authentication email? That seems like an odd location, but ok.

Indeed :)

That sends me to my inbox here -- do you mean, on my own instance?

Nice trick for you: to register a new identity try adding +something after your email username. Example: smith+test1@example.com. That is a secret feature of mailboxes.

Have you already seen this page? maybe useful?

In D25501#14458, @20after4 wrote:

Are there any feed transactions that are visible to logged out users?

Also, the authorization process is rate-limited to 3 emails per hour, preventing me from using that to send an additional test email that way

Play it safe by using phutil_nonempty_scalar() and do not assume that integers are actually integers (because "1" and such)

• Update Map

• Increase line height

Updates map

In D25521#14952, @speck wrote:

Thanks!

(By the way the Filesystem::readFile() does not return a pointer to a (potentially read-only) resource, but it just returns its content - so the concern was nonsense)

In D25515#14983, @aklapper wrote:

In D25515#14842, @valerio.bozzolan wrote:

I wonder if it then, upon deletion of the profile image, it attempts to delete the builtin image

@valerio.bozzolan How is attempting to delete a built-in (!) profile image related to this patch? If I misunderstood, please elaborate. Thanks!

In D25515#14957, @avivey wrote:

I was able to trigger the "missing gd" warning (By uninstalling php*gd), so we're good there.
A bit puzzled about how you got the error if you already have it installed?

In D25515#14842, @valerio.bozzolan wrote:

I wonder if it then, upon deletion of the profile image, it attempts to delete the builtin image

Nice. Maybe a start-extension Arcanist workflow is a bit overkill, but a boilerplate extension would be lovely

Thanks again. Since this is a WIP, let's mark as such.

In an ideal world 1030-1313 could become just: